1. IVOA Beijing Interop May 15-16, 2007 Apps Messaging Issues

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

3. IVOA Beijing Interop, May 16-17, 2007 Message Attributes Sender Sender By Name or ID? By Name or ID? Recipient Recipient By Name or ID? (Hub is a well-known name) By Name or ID? (Hub is a well-known name) Filter mechanism Filter mechanism Subscription group Subscription group Advertised capability Advertised capability General broadcast General broadcast Message ID Message ID Permits async response Permits async response No harm to synchronous messaging model No harm to synchronous messaging model

4. IVOA Beijing Interop, May 16-17, 2007 Message Attributes Reference ID Reference ID Receiving app assigns to object it creates for later reference (e.g. a table subset, intermediate filename). 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 Allows sender app to refer back to that in a later message Acknowledged as generalization, but no consensus on priority Acknowledged as generalization, but no consensus on priority Mtype Mtype UCD-like string giving message meaning UCD-like string giving message meaning Replaces PLASTIC ivorns Replaces PLASTIC ivorns

5. IVOA Beijing Interop, May 16-17, 2007 mtype Explained UCD structure creates message classes UCD structure creates message classes Image display (display.image), table operations (load.table), administrative (get.icon, reply.status), etc 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. Specify core set of mtypes that describe existing app functionality, allow apps to create private mtypes as needed. E.g. displayCore (controlled) mtype class displayCore (controlled) mtype class display.imageSubtype used by convention display.imageSubtype used by convention display.image.frameApp-specific message display.image.frameApp-specific message Intended to map easily to existing Plastic ivorns for backward compatibility Intended to map easily to existing Plastic ivorns for backward compatibility

6. IVOA Beijing Interop, May 16-17, 2007 Issues In-line data In-line data Message carrying a payload of data (complicates?) Message carrying a payload of data (complicates?) Task invocation Task invocation Protocol a minefield, but have current use cases (can we solve with appropriate mtype classes?) Protocol a minefield, but have current use cases (can we solve with appropriate mtype classes?) Legacy environment support Legacy environment support XML-RPC+Other gives us options XML-RPC+Other gives us options Exploiting specific (negotiated) capabilities between apps Exploiting specific (negotiated) capabilities between apps Dont want to hinder collaborations between developers Dont want to hinder collaborations between developers

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

8. IVOA Beijing Interop, May 16-17, 2007 Issues Missing from mailing list discussions: Missing from mailing list discussions: The HUB The HUB General agreement on concept (and name) General agreement on concept (and name) No discussion of what it really does in SAMP No discussion of what it really does in SAMP Client API 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 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 Language-neutral interface description What is keeping groups from Plastic adoption now? 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? Does new proposal satisfy current apps providers? Are they willing to change? Will be buy new friends with it?