Apps Messaging -- A New Approach

[Mike Fitzpatrick]

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