Requirements for a messaging architecture for Olympus.
Here are some issues that we currently have with Galaxy.
- Galaxy doesnâ€™t handle dynamic processes, which we require in the multi-robot domain.
- Galaxy doesnâ€™t seem to be well maintained currently.
- Galaxy is not compatible with any other well-known systems.
- Galaxy has brokering functionality that we donâ€™t need/Too complex for the jobs at hand.
- Galaxy is not from CMU.
- handles messages with arbitrarily nested custom types, support for many low-level property types
- messages are basically human readable, but also in a format thatâ€™s compatible with a large number of existing tools (lisp s-expressions and xml formats are both solutions to (1) and (2))
- at least supports applications written in C, C++, Java, and Perl, and on Windows and Linux
- applications can subscribe and unsubscribe to messages of a certain type.
- well documented
- well maintained/has a large user base
- not proprietary
- api is at a very high level (no need to concern oneself with parsing messages or network code)
Some things that might not be requirements but might count as desiderata.
- messages can be persistent. i.e. applications may request the latest value of X rather than or in addition to message subscriptions.
- integration with a process manager
- mature support tools like loggers and log parsers
- step-through message debugging