Noel Winstanley wrote:
> 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.
The IVOA exec often gets something different than it asked for :–)
With no smiley, I think either path being discussed would be responsive to the WG's charge.
> Although designing a generalized messaging system is attractive I
> don't think that this is what we've been asked for. There's plenty
> of these already in existence - from CORBA, through COM, to SOAP -
> designed by more, and better qualified people than us. Actually,
> some of these aren't even very good - but I doubt our committee
> will design better.
Here you're arguing both ends against the middle. CORBA is the poster child for design by committee. I also don't think that the discussion has been about a generalized messaging system. Whatever "astronomical applications messaging" is, it isn't this. A main architectural question is whether "VOOOM" (or whatever it will be called) will be constrained to applications running on a single host. That doesn't sound like CORBA to me.
I'd also argue that the astronomical software community itself contains many of the "better qualified people". We're a small, but feisty, group that attracts interest from many larger players due not only to the niftiness of the science of astronomy, but also to the interesting bit of computing phase space that astronomical use cases transect.
> 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.
> To me, a standardized messaging system only seems appropriate when
> the applications are substitutable. Where a client is explicitly
> coding against the API of a particular application (be it IRAF,
> VOClient, Aladin Scripting, AstroRuntime), then it may as well use
> that application's own native access method - as the client is
> tightly-bound to the functionality provided by that application
> anyhow.
These aren't applications, these are composite systems each hosting multiple applications. I would think a main point of VOOOM would be to permit these systems to interoperate one with the other. What you're describing is a situation in which a client would have to use different technologies to communicate with each system. In that case, each client becomes its own "hub" and each programmer must develop her own task-specific equivalent of VOOOM.
Rob Seaman
NOAO
Received on 2007-04-16Z17:31:54