Apps Messaging -- A New Approach

[John Taylor]

On 27 Apr 2007, at 06:47, Mike Fitzpatrick wrote:

>
> Hi John,
>
> 	I've been looking through the PLASTIC 1.0 twiki page and
> before I cast my votes, I have a few questions.  Some of these may  
> have
> already have been hashed out in the plastic lists but this is the  
> first
> I've seen some of these things.

Hi Mike,
Thanks for this - it's good to get an opportunity to clarify things.   
As always, when you've got your head down working on something you  
tend to make assumptions that other people don't have.

>
>
> Security
>
> 	The spoofing thing is a minor breach (IMHO), but I pointed it out
> more for the purpose of asking why an app would need to know its, or
> any other, ID in the first place.  It seems to me this is entirely a
> construct in the Hub and shouldn't be part of the user interface since
> it presents some complications (which I'll point out in the use cases
> I've been neglecting to post).

Please do.

> 	While this has a feel-good aura about it, I'd like to see the
> security put off to a later version unless somebody can convince me  
> this
> is a real issue in a one-user, one-desktop system.  Again, I'm just  
> saying
> spoofing=silly_reason_to_have_appID_in_the_interface.
>

This is something I've vacillated about for some time.  Like you, I  
think that application-spoofing is actually pretty unlikely, so I  
wouldn't be in favour of adding a lot of complication in order to  
deal with it.  I'd rather just put a warning on the spec "don't  
expose rm -fr * in your application through the messaging system!".
However, the solution proposed by Mark is simple and elegant and  
doesn't add any significant complexity from the client's point of  
view to what we do already.

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.

Do you have an alternative addressing scheme we should consider?

>
> Generalized Metadata
>
> 	Are you suggesting that all metadata such as the logoURL be
> part of the registration, or that apps adopt a convention of  
> registering
> with the hub and then making additional calls to store the keyword- 
> value
> pairs of the metadata?	I didn't see the former in your hi-level  
> protocol
> API page, and the latter doesn't solve the problem on not being  
> able to
> find metadata for another app, either because it doesn't respond to a
> message or because it was never supplied during registration.
> 	I like the idea of being able to query for metadata about other
> apps, even with asynch messaging though I don't understand what the
> problem is with the current scheme.


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.

In Plastic 0.5, it's all done as one call (and only name and  
supported messages are stored by the hub - all other metadata is  
obtained by sending messages post-registration).  The reason for  
splitting it into two operations (http://www.ivoa.net/twiki/bin/view/ 
IVOA/PlasticOnePointOh#RefactorApi) is to allow you to update the  
metadata without reregistering (I have a genuine use for this, if you  
want to hear it).  The reason for getting the hub to look after the  
data, rather than each app just supplying it on demand in response to  
messages, is my old problem that some clients of the system are going  
to be pure message senders, and won't be able to respond.

I see your point that if an app doesn't supply the data, then it  
can't be obtained (!).  I don't think it's fatal though: if an app  
doesn't declare itself as supporting any messages, it won't receive  
any; if it doesn't declare a logoUrl, you can use a default one; if  
it doesn't declare a name, you can fall back to "Unknown App".

Currently when an application registers, the Hub broadcasts an  
ApplicationRegistered(id) message to everyone who's listening, and  
all the clients know to update their menus etc.  If the new system  
gets adopted by SAMP 1.0 then we'd probably have to add a  
"MetadataChanged(id)" broadcast as well.  Anyway....these are details  
to thrash out later...


>
>
> Message Annotation
>
> 	I don't quite follow how this is supposed to work:  Do I send a
> message asking for the 'hint' first and then if I'm happy send the  
> actual
> message?  Isn't this just a special case of a 'getCapabilities'  
> message?
> 	For the client using this I'd need to either send the hint/actual
> message each time or else keep an internal list of which messages and
> apps have been vetted, or else be lazy and just not use it at all.
>
>

I'll explain how it works currently, and the group can perhaps  
suggest a better way.  To avoid the ire of the registry group I'm  
going to avoid using IVORNS and URI fragments in this example and use  
notation that looks a bit more mtype-like (but is still just made up  
for this example!).  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

On receipt of 2) my receiving app will load the table, on 3) it will  
convert it to a different format (popping up a dialog to ask the user  
for the save location and new format).  On receipt of 1) it will do  
some default behaviour - the purpose of declaring the vanilla mtype  
is just so that sending apps that don't/won't deal with annotations  
can still invoke something useful in the recipient.

When the sender queries the hub to see what mtypes the recipient can  
receive, it will see these 3 mtypes.
Note that the sender doesn't know, and doesn't need to know, what  
@load and @convert do.  All it needs to know is that where it can  
send 1), it can also send 2) and 3).  All it needs to do is satisfy  
the contract specified by us when we defined process.table.votable:  
supply an id and a URL that points to a VOTable.  The sender _can_  
use "load" and "convert" as opaque strings to display to the user in  
a menu.  As a refinement of this we can define other optional mtypes  
that allow the sender to query the recipient for more information  
about the annotations (such as a human-friendly description...thanks  
to Doug Burke for this idea http://sourceforge.net/mailarchive/ 
message.php?msg_id=f07c34ad963e94c96d7b61705e24a444%40cfa.harvard.edu).

Note that neither sender nor receiver is obliged to support  
annotations - if a sender doesn't support them it will just see 2)  
and 3) as unknown mtypes and ignore them.


PS
(@ = AT = AnnoTation!  <-- borrowed from Java 5 )





> MTYPEs vs IVORNs
>
> 	I keep hearing about using message ivorns because of what the
> registry offers, but is this meant primarily to be used by developers
> when writing the apps to see which messages are available, or was this
> seen as a runtime resolution of the ivorn?  If the move is towards
> generic 'loadFits' messages (i.e. "here's a FITS, do something") then
> wouldn't the registry need every app to give its own definition in
> for this to be effective?  I can't imagine runtime resolution would
> work, either from a performance standpoint or the first time anybody
> tried to use this on an airplane laptop.

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.


> 	To push for mytpes again, I claim it would solve some of the
> other issues as well.  For example, an app could query for clients  
> that
> support mtypes like 'display.fits' and 'converTo.fits', matching  
> against
> 'display.*' tells you which tasks have a display functionality and  
> matching
> '*.fits' tells you which apps handle text files.  Isn't that what the
> message annotation idea is about?

They're slightly different in that the annotations are decentralised  
and dynamic - they are created by application authors rather than our  
central committee.  They can also be changed on the fly in response  
to changing circumstances.  Finally, they don't change the syntax of  
the message - if a sender can construct a process.table.votable at load  
message, it can also construct a process.table.votable at convert  
message.  It's not necessarily true that a sender that can send  
"display.fits" can send "display.jpg" or "convertTo.fits".

So, I think annotations and mtypes occupy slightly different spaces  
and are complimentary.  I think mtypes offer a neat way of being more  
systematic than we have been thus far (although I'm not sure about  
pattern matching yet).


>
>
> 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.  I know that we could just look for parameters that begin  
"file://", but the problem is that we sometimes use URLs purely as  
URIs, and not for location.  I don't have a good solution to propose  
for this, especially as I don't want to complicate SAMP with features  
that we might not get round to using. I thought that just by adhering  
to a simple naming convention (e.g. any parameter that's a reference  
could be named url* ) then we could achieve what I wanted without  
burdening the current spec and implementations.  I know it's not  
elegant though.


> 	I read this thinking it
> should be easy enough to distinguish a URL from a filename and since
> we weren't actually sending the content in either case, *everything*
> was a pass-by-reference in some way or another.  If anything needed
> to be standardized here I would think it would be that all filename
> references are required to include a full path (i.e. app A and B might
> have different ideas of the current working directory so telling it to
> simply load 'foo.fits' won't always work).

The pattern we've followed so far is to use URLs for everything, so  
local resources are file:///absolutepath.  The only problem we've had  
with it so far is that some languages (well, Java actually) don't  
produce correct file:// URLs and we had to make sure that we were  
clear on the correct syntax.

 From conversations with Alasdair, I think I also need to clarify  
what's being proposed for
http://www.ivoa.net/twiki/bin/view/IVOA/PlasticOnePointOh#AsynchOnly

I'll try to add something to the wiki today.

Cheers,

John