Meetings 2011-08-02¶
Filtering on Types¶
Problem description:
Scope for Camera settings: /vision/cam/setting Problem: Subscription on /vision User handler gets payloads of different types.
Decisions¶
- Provide templated filtering data handler which allows filtering for specific types per handler
- accepts only the specified data types
Request/Reply Subsystem¶
Client API¶
- Expose two callback interfaces?
- "boxed": Event -> Event?
- "unboxed": RequestType -> ReplyType?
We want to provide both.
- Callback registration in Java?
Callback interface for individual methods
- How do we deal with signatures of remote methods?
- Are signatures of remote methods known at call-time?
- C++:
call<string, string>("echo", "bla")
seems ok - Java:
call<String, String>("echo", "bla")
not possible, right?
Wrong, it can and will be done like this((RemoteMethod<String, String>) getMethod("echo")).call("bla")
?
- Python:
type(arg)
?
We will just trust whatever types the caller supplies - Lisp:
type-of(arg)
,check-type
?
Introspection¶
- Should the client be able to query the server for its set of supported methods?
Maybe later - If so, should request and reply types be included?
likewise
Protocol¶
- Do we need the ability to wait a server to become ready (or rather, for a service to be provided by at least one remote server)?
Maybe later, related to Stefan's issue of knowing the participants of a channel and the meta-event mechanism- Would be convenient for writing the integration test
- Disadvantage: added complexity, source of errors
- Do we need method calls without replies?
No additional infrastructure is required - #458
We will implement this- Disadvantages: less info for logger, Jens; these are easily mitigated by using the method attribute of events appropriately