Meeting 2010-11-10¶

• Sequencing:
  • Spread-specific: -> sequencing only in spread port, remove sequencing stuff from Notification.proto, add second message type only with sequencing information wrapped around serialized Notification
  • Parallelization of sequencing to reduce send and receive times
• Quality-of-Service:
  • Ordered notifications required
  • Ports are responsible, because spread e.g. already can order notifications -> why order by hand here?
  • Extract manual logic for ordering to be reusable
  • Where is the desired service type specified?
    • Probably statically in a global system configuration... later
    • Simple solution right now: QoS-Objekt set at publisher with port observing the publisher, or pub sets the QoS in the port with error if not supported
      • Later maybe also QoS specification at subscriber
  • Current QoS-Types:
    • Unordered
    • Ordered per Subscriber-Publisher pair
• Distributed Nameservice:
  • Event-based telling what's going on on each logical message bus
  • May be replaced with a static system model, but not required
• URL scheme:
  • Hashing of URLs
  • Service required to translate back between hashes to real URLs (nameservice)
  • Hierarchy
• Performance testing:
  • Throughput with spread
  • Why jitter, how to avoid it? Is this only because of the hacked spread?
  • Jitter would be bad for sequencing
• Tool support required
  • Web-Server
  • command-Line tools for introspection
  • Implemented as MVC-Pattern with different views
• Type to data mapping in C++
  • Use RTTI?
  • Benchmark Performance
  • Current steps:
    • Use RTTI to simplify generic interface
  • later:
    • Maybe code generation from model with specific interfaces
    • Hierarchies of types currently ignored