> > 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 Received on 2007-04-07Z08:39:16