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?
    1. "boxed": Event -> Event?
    2. "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