History

Meetings 2011-08-25

RSBag Discussion Part II

Event Serialization

  • TIDELog is designed for interoperability across frameworks
  • RSB-specific serialization of entry blobs is still acceptable (when documented somewhere)
  • CHAN.type field should specify:
    • The fact that RSB events are serialized
    • The type of event payloads
  • CHAN.format field should contain:
    • Data type definition for (outer) event serialization
    • Data type definition for (inner) payload serialization

Meta-data Storage

Something equivalent to Dublin core or similar will probably be added to TIDELog file format.

Protocol Improvements

  • clarify/change semantics of create timestamp
    • Probably requires user-created timestamp
    • Make create time optional?
    • Things like "sensor recording time" should be stored in user timestamps
  • Maybe different message kind (via payload types) can be used
    • For example, sensor messages could include relevant timestamp for the sensor recording case
  • are create, send timestamp necessary under all circumstances?

RSB and Python3.2 (Florian)

  • Conversion of rsb-python code base to 3.2 would work, but the protocol buffer compiler has not been ported yet
  • Currently, the only use-case for RSB and Python 3.2 is embedding in blender
  • Unless urgency increases, it probably makes sense to wait until an updated protocol buffer compiler becomes available

C++ API Improvements (Robert)

  • #517
    • The suggestion did not involve removing the factory
    • Convenience functions for listener, reader, informer creation can be added
  • rsb::Handlers: Why all these methods getMethods(), acceptsMethod(), getClassName() ?!?
    • We discussed the current state
    • Potential changes will be discussed in the next meeting