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