Apps Messaging - Twin track? [was: Re: Apps Messaging - Semantics of a Message

[Doug Tody]

On Tue, 17 Apr 2007, John Taylor wrote:

> Sure, we can do that, although I think we've made a good start on this list. 
> Pierre just highlighted a few things that he'd like to see.  Off the top of 
> my head, my own shopping list would include Pierre's:
> *  drop/make optional the JavaRMI transport
> *  swap IVORNs for mtypes [if we can agree some of the latter quickly enough
> and also
> * make message parameters untyped (in the int vs string vs double sense)
> along with the changes to the API already suggested
> * split and rename some operations
> * remove synchronous messaging
> * add some security.

Judging from this sweeping list of possible changes to PLASTIC from
John, and the statements some of us have already made that PLASTIC
as it stands is too narrowly focused to adequately address the needs
of the broader community which a general astronomical applications
messaging standard must serve, it seems pretty clear that this matter
is not yet close to reaching closure.  The changes above alone would
require an updated document and implementations, which would likely
take us until at least sometime into the summer to complete.

It is not clear to me why this is so urgent, to the point where
getting something out quickly trumps doing a good job.  This sense of
urgency is being driven primarily by the current developers and users
of PLASTIC, which are only a subgroup of the broader community now
involved.  But these users already have PLASTIC, which can continue
to serve this community, possibly with some enhancements inspired
by our discussions here, while the broader applications messaging
standard is developed.

Furthermore, while I agree that PLASTIC has been very successful and
has demonstrated an important new approach to desktop application
interoperability, the project has basically been pursued thus far
via a rapid prototyping approach.  The logical next step in such
a rapid prototyping effort is refactoring, to adjust the design to
reflect what has been learned.  The scope of the effort has changed
somewhat in the meantime.  All of this suggests that we are not yet
close to having an actual standard which can remain stable for a time.
At best we have a functional prototype which be frozen and used for
some months while the next version is under development.

Perhaps what is needed is an updated PLASTIC document, which attempts
to define a PLASTIC interface which is closer to what we think we
may ultimately end up with, plus an ongoing effort to define a more
general astronomical messaging standard.  One requirement for this
would be that it continue to provide something similar to PLASTIC,
with similar ease-of-use and interface, to serve the current class
of applications which now use PLASTIC.  With all the effort which
has already gone into this, it may be possible to have a preliminary
specification and some initial implementations working by the summer
or fall, hopefully with all of us participating this time.

 	- Doug