Apps Messaging - Semantics of a Message

[Mike Fitzpatrick]

        This thread is long enough already so please forgive me for
mixing replies to several messages to respond to just a few points.


Noel writes:

> It is my understanding that it was the real-world success of
> plastic that piqued IVOA's interest in messaging. I talked to
> several of the exec whilst at moscow - the impression I got was
> that their desire was for a plastic-like cleaned-up international
> standard.

    Certainly it was the success of PLASTIC that started the discussion,
but I believe our mandate here is for an 'applications messaging standard'
and not simply a cleaned-up PLASTIC.  To the extent PLASTIC can evolve to
meet the needs of all apps then that is a valid path, but we've already
identified several use-cases (both specific and more general philosophies)
where this becomes a problem eventually.  If PLASTIC didn't already exist
I think everyone would be happy with a quick implementation that does
the plastic-like messaging *so long as* we had a basic framework where the
other cases could be added easily later on.  Knowingly excluding a certain
set of use cases because what's in use is "good enough for now" is not
the best we can do.

    This doesn't mean the intent here is to scrap PLASTIC immediately.
Hopefully the new standard will be compelling and similar enough that
developers would naturally move to it.  The 'mtypes' being discussed are
similar enough to the plastic messages that a Hub implementation could
provide a translation and deliver plastic to an app if that's all it
understands (at least for some transitional period) so we don't need to
repeal existing functionality or have competing, incompatible, systems.
Whether this is practical depends on whether current apps use plastic with
the same kinds of REQUEST/NOTIFY/REPLY (assuming that becomes part of the
spec) concepts, broadcasting, asyncrony, etc.  Regardless of whether we
pick a switchover date or a transition plan, this is a separate (to be
had) discussion from what a general applications messaging system should
look like.



Rob and Noel share thoughts on:

> > I'm not convinced that invocation and data-exchange are similar
> > enough to make it worthwhile to fit them within the same (family
> > of) standards.
>
> This is an interesting take on the discussion.  The fundamental issue
> is whether interoperability is a requirement.  If not, then two (or
> more standards) are a viable option.  On the other hand, if functions
> like "data-exchange" must be interoperable with functions like
> "invocation", then both must be realized by the same design.  That
> design, however, may permit staged or partial implementations.
        I think what we want is a messaging system flexible enough that
it can be used either for invocation or data-sharing, and in a mix
of apps that either do or do not assume who the recipient will be.
This doesn't require anything nearly as complex as CORBA but is the
reason we'd like to separate the meaning of a message from the syntax,
the transport method from its implementation, etc.  I don't see sending
a filename as an operand to some GUI functionality or as an argument to
as task call as being all that different, except in the philisophy of
"here's an image, do something".  In the current plasticized apps each app
has one core functionality (image display, table viewer, plotter, etc)
where that make some sense;  the other philosophy desires to have finer
messaging to exploit more capabilities of indivual apps (e.g.  load image
into this display, plot these columns of a table, perform this operation
on this combination of table and image, etc).


> To me, a standardized messaging system only seems appropriate when
> the applications are substitutable.

        Personally I think the apps should ne substitutable, and I (tried
at least) to make the case earlier by saying an mtype implies a capability
and app is avertising as well as a search by a sender for somebody able
to handle that request.  If you want a specific implementation of that
capability you send to a specific app by name, and if Aladin doesn't handle
the an IRAF task message it is free to reject/fail.


        Anyway, it's probably time for a summary posting on the twiki to
identify points of agreements and debate.  I'll try to add that shortly
since John is away this week.


Cheers,
-Mike