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
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
Received on 2007-04-27Z22:28:05