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.
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).
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.
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.
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.
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.
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?
Pass-by-reference Parameters
Have you got a specific use case here? 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).
Thanks for the clarification,
-Mike
Received on 2007-04-27Z07:48:00