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.