Robotics Service Bus

h1. Meetings 2011-06-08

h2. RSB 0.3

* Current state can be released
** Reply from spread people 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
** #354

* Component List
** Has to be updated

* Outlook
** Naming, Service discovery
*** Distributed (e.g. mdns, upnp, etc.)
** Tools, in particular introspection, logging
*** 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 Layer
*** 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. Topics

* 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
* 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_
*** 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