Apps Messaging - Semantics of a Message

[Mike Fitzpatrick]

> >     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).
>
> Erm... we're straying into bits of spec here that will hideously
> complicate things, while admittedly making the protocol more
> powerful. I'm not convinced this is needed (Re my arguments about the
> conceptual approach to messages).

How tricky it is depends on how the spec is written.  The case I had in
mind was e.g. requesting that an app crossmatch/intersect two tables
and this app creates a new internal table.  From the GUI this may be
a new window you could interact with, but how would I address that
new table (e.g. to make a new query/plot of it) without knowing it's internal
reference?  The refID allows a REPLY to create some sort of handle for
that internal thing that could be recognized later.  We don't need the app
to keep the state, a REPLY could register the refID with the Hub in some
sort of lookup table.  The alternative is to assume everything is file-based,
but that has complications as well.


> >       In this model, clients can determine for themselves how many other
> > apps are available, what their capabilities are, etc.
>>             :
> Okay, although I'm worried that this could start to needlessly
> complicate things, I'm really keen to maintain "simple" as the
> overriding definition of this specification.

The spec *can* remaiin simple in this respect, but we get
flexibility in how complicated individual clients want to be.  A
number of the msg systems I looked at started by allowing
both synch/asych delivery and moved strictly to asynch since
it was more tolerant to failure of apps and the synch behavior
could be coded if needed.


-Mike