IVOA Beijing Interop

1
Apps Messaging Issues
2
Message Concept

• Message Classes
• NOTIFY
• Informational, no response/confirmation (e.g. app
  (dis)connected, logging, etc)
• REQUEST
• Request action from another app, rejection OK
  (e.g. loadFromUrl)
• REPLY
• Returns status code or result of a REQUEST
• Msgs have attributes defining the meaning, some
  required, some optional

3
Message Attributes

• Sender
• By Name or ID?
• Recipient
• By Name or ID? (Hub is a well-known name)
• Filter mechanism
• Subscription group
• Advertised capability
• General broadcast
• Message ID
• Permits async response
• No harm to synchronous messaging model

4
Message Attributes

• Reference ID
• Receiving app assigns to object it creates for
  later reference (e.g. a table subset,
  intermediate filename).
• Allows sender app to refer back to that in a
  later message
• Acknowledged as generalization, but no consensus
  on priority
• Mtype
• UCD-like string giving message meaning
• Replaces PLASTIC ivorns
• ltArglistgt

5
mtype Explained

• UCD structure creates message classes
• Image display (display.image), table operations
  (load.table), administrative (get.icon,
  reply.status), etc
• Specify core set of mtypes that describe existing
  app functionality, allow apps to create private
  mtypes as needed. E.g.
• display Core (controlled) mtype class
• display.image Subtype used by convention
• display.image.frame App-specific message
• Intended to map easily to existing Plastic ivorns
  for backward compatibility

6
Issues

• In-line data
• Message carrying a payload of data (complicates?)
• Task invocation
• Protocol a minefield, but have current use cases
  (can we solve with appropriate mtype classes?)
• Legacy environment support
• XML-RPCOther gives us options
• Exploiting specific (negotiated) capabilities
  between apps
• Dont want to hinder collaborations between
  developers

7
Issues

• Messaging Models
• Current Plastic assumes GUI, what about
  distributed-applications model? Future
  inter-desktop messages?
• Pub-Sub message model
• P2P vs Broadcast delivery
• Sync vs Async or Both
• Message groups
• Multiple instances of an application
• Failure modes and Error handling
• User-configurable message handlers
• What level of security is practical to implement?

8
Issues

• Missing from mailing list discussions
• The HUB
• General agreement on concept (and name)
• No discussion of what it really does in SAMP
• Client API
• Actually a definition of Hub interface, e.g. we
  describe the Send() method but in the spec we
  must describe the conversation with the Hub, e.g.
  send() returns a messageID even if final client
  API doesnt show it to the user
• Language-neutral interface description
• What is keeping groups from Plastic adoption now?
• Does new proposal satisfy current apps providers?
  Are they willing to change? Will be buy new
  friends with it?