Meetings2011-08-02 » History » Version 2

Version 1 (J. Moringen, 08/01/2011 11:00 PM) → Version 2/3 (S. Wrede, 08/02/2011 10:25 AM)

h1. Meetings 2011-08-02

h2. Filtering on Types

Problem description:
<pre>
Scope for Camera settings:

/vision/cam/setting

Problem:
Subscription on /vision

User handler gets payloads of different types.
</pre>

h3. Decisions

* Provide templated filtering data handler which allows filtering for specific types per handler
** accepts only the specified data types

h2.
Request/Reply Subsystem

h3. Client API

* Expose two callback interfaces?
*# "boxed": Event -> Event?
*# "unboxed": RequestType -> ReplyType?
* Callback registration in Java?
* 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?
*** @((RemoteMethod<String, String>) getMethod("echo")).call("bla")@?
** Python: @type(arg)@?
** Lisp: @type-of(arg)@, @check-type@?

h3. Introspection

* Should the client be able to query the server for its set of supported methods?
* If so, should request and reply types be included?

h3. 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)?
** Would be convenient for writing the integration test
** Disadvantage: added complexity, source of errors
* Do we need method calls without replies?
* #458
** Disadvantages: less info for logger, Jens