Hi AL,
> ......
> Of course its going to be difficult, near impossible, to support any
> legacy environment that doesn't have the concept of sockets. I don't
> think we really want to deal with the added complications of
> environments that don't support sockets, we have to draw the line
> somewhere.
Fixing this particular problem is more a matter of developing a suitable API than anything in the protocol, in fact I plan to implement all this in the C-based VOClient API do Fortran and the few of us still writing (IRAF) SPP can use it and be safely shielded from the details of the connection, serialization and transport.
> > Missing Concept: A data payload with the message instead of a
> > simple file reference.
>
> Actually, I don't think this is a good idea. Having the ability to
> push data inline vastly complicates the protocol because it necessary
> to support arbitrarily large messages.
I agree, but I thought the purpose of these use cases was to point out things we'd want in the general case. I wasn't suggesting this, or any of these, for the short-term.
> Interesting concept, but in general how does this significantly
> improve the protocol. Concentrating on the simple, how does this
> capability improve a users/developers life? I'm not really sure how
> the above generalises to something that people will need enough to
> justify adding additional complications to the protocol.
Process groups like this can be used when a set of tasks all perform more or less the same function and you want to identify them as related in that way rather than by name or as a broadcast to everyone. For GUI desktop apps they're less useful (although grouping 'display' vs 'plot' tasks might have uses), but again this was a generalization for later that considered distributed processing like a small pipeline as the primary user and not strictly the desktop.
> > 4) a) I want to display a 2-D image to any application capable of
> > rendering
> > it on the screen for me.
>
> PLASTIC can of course do this...
What I had in mind was an way to find out whether any app had the ability, not simply display to e.g. Aladin because I could see if it was running and I knew what it did. See my comment to John's earier posting about why I'm not convinced the message fragments are the best solution, but I'll agree that if that's the way we go they could be used here.
> > Missing Concept: "Context Messages" to create a unified view of
> > the desktop between all applications.
>
> This is a platform specific concept, and is highly contextual, adding
> potentially huge amounts of arbitrary complexity.
Maybe just another desktop GUI vs distributed app perspective difference again: With current PLASTIC apps I just open then from any window on my screen and most often these won't all be in the same directory. After processing for a while and downloading files and saving results from different apps I could end a session with files all over the place, surely you can see a practical benefit to at least a 'cd' context? Implementation wise this is nothing more than a broadcast message of a special type, what may be 'missing' however is the idea of using broadcast messages in plastic in this manner?
Cheers,
-Mike
Received on 2007-04-30Z08:49:29