Apps Messaging - Semantics of a Message

[Mark Taylor]

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 at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/