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
Received on 2007-04-16Z20:54:41