Apps Messaging -- A New Approach

[Mike Fitzpatrick]

Hi John,

On Fri, 27 Apr 2007, John Taylor wrote:

> As for using IDs in the system, rather than just an application's  
> name, this is the result of a debate we had early on in PLASTIC.  We  
> asked the question of our users "would you ever want to run two  
> instances of the same program?".  The answer was yes, so we needed to  
> be able to distinguish them by assigning them unique IDs.   I agree  
> that these should not be usually shown in the UI: that's what the  
> application's name is for.  Each application has its own way of  
> displaying applications with identical names: Topcat, for instance,  
> appends "1,2,3...." after the name, but under the hood these map to  
> "globally agreed" IDs.

	Your users may have been anwering with the idea of being able to
display to the app on the left-hand monitor only, but the appID doesn't
help distinguish which one this really is.  In the case of multiple
instances of an app I can see sending data to only one for processing, but
assuming the user doesn't care which (I'm thinking of a non-GUI "worker"
app case) it's easy enough to query for the appID and send a directed
message.  We probably do need one or two methods in an API that exposes
the id for a particular purpose, I was objecting to the current API where
it seems to be used everywhere.


> Do you have an alternative addressing scheme we should consider?

	The API can probably support any number of these, e.g. a directed
message to an app by ID or name, a broadcast to all apps willing to accept
a particular message type.  Internally the API may be required to identify
the app when talking to the Hub and we can have different levels of
interface, but a hi-level interface that allows 'broadcast("Hello World")'
and 'send("topcat", fname)' will satisfy a lot of lay-users with science
code and leave the lo-level stuff to the geeks building the tricky bits.


> I'm proposing that you'd make one call to register (only), and get  
> your privateId.  You'd then make another call to the hub to store  
> your metadata: name, description, logo, supported messages & misc  
> other info. ....

	I'll wait until the debate about what format the logo is required
to be in starts before getting to involved in this.  Something implicit in
your explanation though is that the Hub must maintain the metadata for
each app individually based on id (since an app can change something with
a MetadataChanged(id) as you say);  Presumably there would be some
duplication of the description/logo/etc for multiple instances on a
dekstop but that is minor.  If this were to expand to a inter-desktop
system in the future though (e.g. where 'smart' hubs could pass messages
to bridge machines) then do all machines keep all information for all apps
concurrently?  The on-demand messages to get the metadata would avoid this
entirely.
	If an app supplies the metadata at all (either as part of the
registration or as separate calls) an API could still respond to the
requests automatically in the listener interface even if these never
get passed up to the app for special handling (i.e. "built-in messages").



> > Message Annotation
> >
> Consider an mtype used to request that an  application "loads" a table:
> 
> process.table.votable with parameters (id="nobel prize", url="http:// 
> foo.com/adf")
> 
> We (this group) define this mtype and the argument list that goes  
> with it.  An applications that supports (ie, can receive) this  
> message is free to annotate it with non-standardized annotations, for  
> example,
> 
> process.table.votable at load
> process.table.votable at convert
> 
> On or after registration, the application would declare that it  
> supports:
> 
> 1) process.table.votable
> 2) process.table.votable at load
> 3) process.table.votable at convert

	I'm still not sold, angering the registry zealots by using ivorns
might have made for a more compelling example though.  Persumably we
would need a small, controlled vocabulary for these annotations to be
meaningful to machines, and apps would be free to make up their own.
So, how is annotation any better than simply using mtype classes such as

	1) process.votable
	2) load.votable
	3) convert.votable

You can still send the data to any app responding to a *.votable message,
use the generic 'process.votable' to get the default action or one of the
others to get a specific action.  An annotation such as
'process.table.votable at flibbity' is essentially a private message since
I would have to know what the 'flibbity' did to use it, same as I would
for a 'flibbity.votable' mtype class.
	If the annotation is strictly for human readable GUI menus I'd
prefer to see it as a 'getDescription' type of message.


> > MTYPEs vs IVORNs
> >
> I want to stress that as far as PLASTIC 0.5 is concerned message  
> IVORNS are just opaque strings - they do not need to be resolved in a  
> registry.  The idea was that in the future we might make use of the  
> fact that they could be registered, but not in such a a way that  
> you'd need to contact a registry in order to use the messaging  
> system.  We're no closer to registering message IVORNS now than we  
> were 18 months ago, so I don't think many of us will fight hard to  
> retain them.

	Then can we agree to just not use them?  The only argument for
them is that they would be registerable, but they are not at all unique
if each an every app is free to define individually how it would handle
a 'loadFITS' message.  I seem to remember a service for UCDs that would
take plain text and try to find a valid UCD, perhaps a similar service
for mtypes would help develops find the right mtype to use rather than
relying on the registry as a repository for this.  Even a small app that
printed out all messages understood my all connected apps would at least
let a developer know what his available 'toolkit' is and would be 
independent of the versions of the apps being used



> > Pass-by-reference Parameters
> >
> > 	Have you got a specific use case here?
> 
> Not a very pressing one.  I know that we're only supposed to be  
> considering apps on a single machine, but I'm looking ahead to when  
> we might have a more general system that sends messages off the  
> desktop.  If we want to plug SAMP into that, then we'd need a way of  
> identifying parameters that referred to local resources so that a  
> "gateway/bridging" component could spot them and stage the data  
> across.  

	IRAF networking's done this for 20 years:  resources can be
addressed as "node!whatever" and the system internally accesses the
remote resource (tape drive, file, image display, etc).  The 'whatever'
could still be a URL or local file name, it could even be an appName.



Cheers,
-Mike