Apps Messaging Issues IVOA Beijing Interop May 15 -16, 2007
Message Concept n Message Classes n NOTIFY n n REQUEST n n Request action from another app, rejection OK (e. g. load. From. Url) REPLY n n Informational, no response/confirmation (e. g. app (dis)connected, logging, etc) Returns status code or result of a REQUEST Msgs have attributes defining the meaning, some required, some optional IVOA Beijing Interop, May 16 -17, 2007
Message Attributes n Sender n n By Name or ID? Recipient n n By Name or ID? (Hub is a well-known name) Filter mechanism n n Subscription group Advertised capability General broadcast Message ID n n Permits async response No harm to synchronous messaging model IVOA Beijing Interop, May 16 -17, 2007
Message Attributes n Reference ID n n Mtype n n n 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 UCD-like string giving message meaning Replaces PLASTIC ivorns <Arglist> IVOA Beijing Interop, May 16 -17, 2007
mtype Explained n UCD structure creates message classes n n 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. n n display. image. frame Core (controlled) mtype class Subtype used by convention App-specific message Intended to map easily to existing Plastic ivorns for backward compatibility IVOA Beijing Interop, May 16 -17, 2007
Issues n In-line data n n Task invocation n n Protocol a minefield, but have current use cases (can we solve with appropriate mtype classes? ) Legacy environment support n n Message carrying a payload of data (complicates? ) XML-RPC+Other gives us options Exploiting specific (negotiated) capabilities between apps n Don’t want to hinder collaborations between developers IVOA Beijing Interop, May 16 -17, 2007
Issues n Messaging Models n n n n n Current Plastic assumes GUI, what about distributedapplications model? Future inter-desktop messages? Pub-Sub message model P 2 P 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? IVOA Beijing Interop, May 16 -17, 2007
Issues n Missing from mailing list discussions: n The HUB n n n Client API n n General agreement on concept (and name) No discussion of what it really does in SAMP 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 message. ID even if final client API doesn’t 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? IVOA Beijing Interop, May 16 -17, 2007
Скачать презентацию Apps Messaging Issues IVOA Beijing Interop May 15
cb2aa8ad8bab19790c8e97d0a0ad9af9.ppt