Robotics Service Bus

h1. Meetings 2011-06-08

h2. RSB 0.3

* Current state can be released
** Reply from spread people (see #309) does not block the release
** #338 has been resolved

h2. Examples in RSB Wiki

* We should have one example (Wiki page) for the following scenario
** Three participants
** In-process communication
** Spread-based communication
** Configuration for this scenario

* Documentation of binary package installation
** see #353

* Examples
** Ideally, examples from repository should be included in Wiki pages as listings
** Fallback: copy listings from repository into Wiki pages

h2. Presentation of RSB

* Future RSB meetings
** External participants
** Thu 14:00h

* Framework Comparison Wiki Page
** See #354

* Component List
** Has to be updated

* Outlook
** Naming, Service discovery
*** Distributed (e.g. mdns, upnp, etc.)
** Tools, in particular
*** Introspection
*** Logging, Replay
** Platforms
*** Web integration (WebServices)
*** XMPP
*** Mobile devices
*** DNLA (streaming, etc.)
** Timing
*** Time-informer
**** Clock source
**** Synchronization
*** Associated Patterns
**** Clock-driven behavior
**** Clock-based filtering
** Model Layer/Component Model
*** Role of @Service@ class
** Framework Interoperability
** Plugin Mechanism (for C++)
** Content-based filtering
*** ProtocolBuffer layer
*** Ideally, without unpacking

h2. #338

* RSB 0.3
** "string" wire-schema means ASCII-string
* Future releases
** There should be two string types: utf-8-string and ascii-string

h2. Protocol Buffers

* Should dictionary keys in meta-data (@UserTime@, @UserInfo@) be ASCII- or UTF8-strings?
** Should be ASCII
* #176 what is meant by TTL in the context of RSB events?
** Could be used for temporal filtering (e.g. discard old events); Implementation in future release
* When generating multiple notifications for one event, only include meta-data in the initial/final notification?
** Efficiency should be improved, but in a future release

h2. Informer Semantics (and Enforcement)

* Should a client be allowed to send data which is not of the Informer's configured type?
** -Only sub-types of the declared type- (maybe later)
** Only data of the declared type should be sent
** Runtime errors should be signaled in case of violation
* Should a client be allowed to send to scopes which are different from the Informer's configured scope?
** Only the declared scope is allowed
** Runtime errors should be signaled in case of violation