|
- How do we balance the need for messages to be general enough for max interop, with the specificity needed to exploit the full power of an app? Comment
- Messages might mean different things to different apps. E.g. a 'loadImage'message might mean to render it for display to one app, plot its histogram to another, or stage it for processing to third. How do we deal with this? Comment
- Do we need to be concerned with obsolescence of messages? Comment
- In a Hub-based architecture, should the hub have any concept of the meaning of messages? Comment
Data Transport
- What data formats should we use?
- Do we need to send a data subset (i.e. rows from a table or image ROI only)?
- Do we need to share access to data (rather than passing references and each app making a copy)?
Comment
Intradesktop Messaging Questions
General
- Is a hub-based architecture best or should it be peer to peer or something else?
- Do we need to be able to partition apps within a hub into separate mutually inaccessible groups?
- Do we want a request-reponse style messaging?
- Asynchronous messaging?
- Polling?
Comment
PLASTIC-specific Questions
The following questions are to gauge how suitable PLASTIC is as a foundation for the restricted case of intradesktop application messaging:
Compatibility
- Can your application send and receive messages via PLASTIC?
- Could you embed a PLASTIC Hub in your application?
- If not, what's stopping you?
Ease of use
- Should PLASTIC have more underlying transport protocols?
(e.g. UDP broadcasting, JMS, http-get)
- Should PLASTIC have fewer underlying transport protocols?
- What would you change in the PLASTIC API?
- How do we deal with a multi Hub world?
- Do we need a protocol for "handover" as one hub shuts down?
Power
- Is the PLASTIC model of a message as a simple string accompanied by arguments, with "method call"-like semantics adequate?
- If you could use PLASTIC, but it doesn't do enough for you, what is missing?
- If PLASTIC were replaced by something else, what features of PLASTIC do you like and would like to retain?
Comment
Beyond the desktop
Inter-application messaging will typically be only on a single
machine, however there may be cases where a general application
messaging system might involve more than one computer. For instance,
a remote compute cluster pushing data to a desktop app for visualization, a server process providing access to a remote resource, etc
- Is there a demand for collaborative data exploration?
- What technologies are there that could facilitate this, and cope with firewalls, NATS etc?
Comment
- Is this any of our business or is this a GWS issue?
Comment
And finally...
- The term 'Applications' should not be limited to the current suite of desktop tools, we should consider any application one might imagine
- What should our target be for May?
Comment
-- JohnTaylor & MikeFitzpatrick - 07 Feb 2007 |