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:
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 Received on 2007-04-27Z14:43:01