Identifying apps [was Re: Apps Messaging -- A New Approach

[John Taylor]

On 27 Apr 2007, at 21:27, Mike Fitzpatrick wrote:

> 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.

At the moment it doesn't - you're right.  No one has complained yet.   
If they did, it's easy to imagine how you could fix this with a new  
message: "blink".  As the user is choosing the recipient application  
in the sender app, when his mouse hovers over each possibility a  
quick "blink" message is fired off to the app under the mouse cursor,  
which responds by highlighting itself in some way.


> 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.
>

The API already includes a broadcast("Hello World") operation that  
will pass a message on to anyone that understands "Hello World".    
So, moving on to the case of sending messages from one application to  
just one other, we need some mechanism of identifying the recipient 
(s).  I'd also argue that we need a way of identifying the sender so  
that the recipient knows where the message comes from.  We've got two  
main choices:
1) IDs are assigned by the hub
+ guaranteed unique
+ allow us to be secure (you don't get an id if you can't prove  
you're entitled to one)
- not human-friendly ("I just got a message from plastic:// 
adfhlkasdhfkahsf !")


2) Assigned by the application
+ Probably human-friendly
+ Can dispense with the registration step
- Not unique - cannot distinguish between two instances of the same app
- Possible (though unlikely), that two different applications with  
different capabilities register with the same name (with hilarious  
consequences).


My preference for 1) is that it's more watertight, and its main  
disadvantage (machine-orientated Ids) can be worked around - you just  
ask the hub for the name of the app with that Id.   Mike - is 2) an  
accurate description of your position?  If so, I'll add it to the  
wiki page so that people can choose between them.

There's also a compromise possibility, in that we use scheme 1), but  
we add a convenience method to the hub that does the reverse  
translation from the app name to its ID on the sender's behalf  
(perhaps using pattern matching).  So, you'd get your send(sender-id,  
"topcat", message) method (which would make sending messages from the  
commandline a little simpler).

John