Apps Messaging - Twin track?

[Mike Fitzpatrick]

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