History

Meetings 2011-06-08

RSB 0.3

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

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
  • 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
  • Component List
    • Has to be updated
  • Outlook
    • Naming, Service discovery
      • Distributed (e.g. mdns, upnp, etc.)
    • Sychronization primitives
      • E.g., AV Fusion
    • 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

#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