> > 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:
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 Received on 2007-04-30Z10:23:27