Meetings2011-06-08 » History » Version 13
« Previous -
Version 13/14
(diff) -
Next » -
Current version
J. Moringen, 06/09/2011 11:03 PM
reference to spread issue
Meetings 2011-06-08¶
RSB 0.3¶
- Current state can be released
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
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
- Time-informer
- Model Layer/Component Model
- Role of
Service
class
- Role of
- Framework Interoperability
- Plugin Mechanism (for C++)
- Content-based filtering
- ProtocolBuffer layer
- Ideally, without unpacking
- Naming, Service discovery
#338¶
- RSB 0.3
- "string" wire-schema means ASCII-string
- Future releases
- There should be two string types: utf-8-string and ascii-string
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(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