Mike,
thanks for your messaging proposals, they contain a lot of useful clear thinking. Here are a couple of further comments:
On Fri, 6 Apr 2007, Mike Fitzpatrick wrote:
> MESSAGEs can be described generally as being a NOTIFY, a REPLY,
> or a REQUEST message. NOTIFY messages are purely informational and require
> no response or confirmation of delivery. A REQUEST message is one that
I think that labelling messages as NOTIFY, REPLY, REQUEST is a good idea as it captures the kind of job it's trying to do; this message classification can stand as boilerplate which will reduce the amount of additional documentation required per mtype.
> refID An ID assigned by an app to be used as a reference to a
> result object in future messages it may receive. In some
> cases this may be an opaque handle to something like "the
> image you loaded in the display", in other cases it can be
> de-referenced to an actual file/image that was created
> (e.g. the output of a "Save Image" message). Applications
> may choose to not return a refID if it is a purely
> transient result (e.g. a plot of an image histogram where
> the data for the plot is not saved) or cannot meaningfully
> be referenced by a later message (e.g. a subset of table
> rows that may be highlighted but cannot be addressed as a
> new table).
For many messages there will be no application for this, but I think it could be a useful abstraction in several cases where you're creating some object which you might want to refer to later; it's something that we've found ourselves reinventing for various different messages in PLASTIC.
> sender The <appName> of sender application. The Hub will supply
> this attribute to the receiving application. The
> implementation should not require that a "sender ID" be
> present in a message request since this allows spoofing
> of the message and the application IDs are more properly
> suited as being an attribute in the HUb than in an app
> knowing what the Hub assigns as some ID. Just as there
> may be multiple identical instances of a Recipient, a
> Sender should be likewise free from a specific instance
> defined by a Hub ID.
while spoofing is a problem (addressed in other messages today) I think it does make sense to identify different instances of the same application as different items, so I'd say a unique (per session) application ID of some sort would be a good thing.
> arguments A whitespace-delimited string specifying the arguments of
> the message. In the case of a REPLY message this will be
> either a string containing the response value, or in the
> case of a request that does not return a value, one of the
> reserved strings:
>
> OK Request was executed w/out error
> ERR Request encountered an error
> REJECTED Recipient refused to process the request
> DELIVERED Recipient received the message but did not reply
Sending the arguments as a single whitespace-delimited string is likely to lead to hard work for the receiving application which needs to parse them, and it may limit the kind of arguments you can send (for instance it may be fiddly or impossible to use argument strings containing embedded whitespace). How about using the same mechanism for sending the arguments as for sending the message attributes? In this case a message would consist of a number of key-value pairs; some of the keys have meanings defined by the protocol (mtype, msgid, refID, ...) and others have meanings defined by the message (the mtype): for instance url, ra, dec etc. In order to avoid blurring the types and avoid clashes it may be wise to use a reserved namespace for attributes, e.g. _mtype, _msgid, _refID.
To respond to Doug's comment about wanting various alternative argument transport formats, this could be only one (the default?) of several possible argument transport formats. For instance instead of passing individual arguments in this way you could have a single _argblock attribute which passes a packed data structure containing the information.
Mark
-- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/Received on 2007-04-10Z16:37:38