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

[Mike Fitzpatrick]

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

	"Blinking" a window is pretty platform-specific, if it can be done
at all!  I think appending a running number to the appName is perfectly
reasonable but isn't required.  For example, if we have two apps
registered as 'topcat' the we could simply specify in the protocol that a
SEND would go to the first of these to register, and a BROADCAST would go
to both. The hub (and probably the user) would know which was first and a
sender app could still present a 'SendTo' menu item (or 'Broadcast') item
listing the app by name (or a SenTo with an 'All' option, etc).
	We should remember that we need to focus on what the protocol says 
will happen in the event of multiple instances of an app, doing everything 
by a unique appID is one way to implement that but isn't the only way.  

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

	Actually as far as the protocol goes I think 1) is the way to do 
it.  Remember, my objection is to having the id in the API but there will
be many different versions of the API based on the protocol defined here.
>From an API and user standpoint, using the app names is friendlier.
	Suppose we mandate the following:

	- Apps must all be registered with a unique name
	    - The Hub will reject the registration if an app by that 
	      name already exists in the Hub
	    - The register() method will append a running number to the
	      appname and resubmit until registration with the Hub 
	      succeeds
	    - Upon success, the register() method will return a unique
	      id for the process (could include the security thing)
	- Client apps are required to send their ID along with each
	  message.
	- Recipient apps will get both the send/receiver ID as part of
          the message content

The name/id translation is then just a lookup table and we could require
there are methods to translate.  You could write an API using the ids, I
could write one where register() returns the appName and my send()
thereafter uses my id silently from a static variable in the API for
send() without requiring sender info in the arglist at all, and does a
name translation via a local lookup in my API or as overhead to an extra
msg to the Hub for the recipient id.  The Hub and protocol are then built
around the ID for later generality but we each built the API that we think
our users want in their procedure calls.  We get interop w/ apps that only
know how to deal with id in the content, and if my API wants to do pattern
matching I can implement my own lookup table to build on top of the
primitives provided by various lookup methods (ivorns make this nasty, and
I'd prefer that the Hub sort this out for me).


-Mike