-
Notifications
You must be signed in to change notification settings - Fork 12
/
Copy pathTODO
55 lines (43 loc) · 2.21 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
* Add working examples of nginx modules that use protobuf messages.
- working version of user cookie filter module described in the
README.md.
- protobuf RPC module (reads input message from request body of
a POST, responds with serialized output message). Can be used
as an example of what code generation of services would look like.
- logging module (access logs in protobuf format). Can write
compressed logs of {length, message} pairs. Should include a
simple utility to parse the gzipped protobuf logs.
* Extend pack/unpack methods to handle incremental pack and unpack.
- on pack, methods should return NGX_AGAIN if they need more space
to pack the entire message.
- on unpack, return NGX_AGAIN if we need more data to finish a field.
note that it's possible to return NGX_OK even not all of the input
has been parsed (e.g. if we finish a repeated field exactly at the
boundary, we will return NGX_OK, but additional input can add more
fields).
- state should be saved to / restored from the protobuf context.
for nested messages, this may include a stack of some kind.
- caller should check the context to see if the pack or unpack was
complete when expected to be.
* Add support for default values.
- when a message is fully unpacked, any missing fields with default
values will be initialized to those values.
* Consider how / whether to handle services in the .proto files. from
the protobuf documentation:
service SearchService {
rpc Search (SearchRequest) returns (SearchResponse);
}
this is supposed to define an RPC interface that takes a SearchRequest
and responds with a SearchResponse. in nginx, we could generate a
SearchService (ngx_search_service) module that has a handler in it
that expects a POST of a serialized ngx_search_request_t object, and
responds with a serialized ngx_search_response_t object. the module
can take care of everything except filling in the actual body of this
function:
ngx_search_response_t *
ngx_search_service_handler(ngx_search_request_t *req);
in the nginx config, the handler would be invoked as:
location = /searchService {
ngx_search_service;
}
or something along those lines.