Proposed changes to PLASTIC for 1.0

All of the following changes can be implemented as changes in the Hub without requiring that applications immediately switch to 1.0. That is, a Hub can support both v0.5 and v1.0 of the protocol. Some of the changes are more difficult (and inelegant) to implement and maintain backwards compatibility than others, as indicated in the comments.

See InterOpMay2007AppsMessagingMinutes for the decisions taken on these changes.

Please see Appendix A of the IVOA Note on PLASTIC for definitions of terms used.

Category		API & Infrastructure						Messages					Transport
Change	Do Nothing	Security	Refactor API	Message Ids	Generalise metadata	Drop Synch Messaging	Bootstrap method	Use mtypes	Message annotations	Message params untyped	Message params by name	Distinguish references	XMLRPC only	XMLRPC + optional	All optional
Proposer		MarkTaylor	JohnTaylor	MikeFitzpatrick	JohnTaylor	MikeFitzpatrick		MikeFitzpatrick	JohnTaylor	JohnTaylor	MarkTaylor	JohnTaylor		JohnTaylor
Votes ++/+(for) --/-(against) blank(neutral)
JohnTaylor	-	+	++	+	+	+	--		++	++?	++?	+??		+
MarkTaylor		+	+	+	+		-		++	+	+	-	+	-	--
AlasdairAllan		+				--	-			++			+
BrianWalshe	-	+	+	+		++	-	-	+				+
PierreFernique				+		+	--	+		++
ThomasBoch		+	+	+			--	+			+		+	-	--
NoelWinstanley		+	+	+		--	--	-	+		+	-	+		--
IsaBarbarisi		+	+	+		+	--	+	+		+		+	-	--
MarcoComparato		+	+	+	+	+	--			+		-	+
MikeFitzpatrick	--		++	+		+		++		+	+	-	-	++	-
LuigiPaioro	--	+	++	+	+	-		++			++		--	++	-
VivekanandaMoosani	--			+		-	--		+		+		-	+	-
CopyMeAndOverwrite	Do Nothing	Security	Refactor API	Message Ids	Generalise metadata	Drop Synch Messaging	Bootstrap method	Use mtypes	Message annotations	Message params untyped	Message params by name	Message URL params	XMLRPC only	XMLRPC + optional	All optional

Do Nothing

A perfectly reasonable point of view!

Security

PLASTIC 0.5 allows clients to spoof each other, and potentially allows unauthorized access to a user's Hub (though this can be mitigated by using a firewall). Some simple changes described in ApplicationsMessagingHighLevelProtocol should fix this.

Backwards compatibility?

OK, but if clients can still use PLASTIC 0.5 to connect to the Hub then the added security is going to be worthless. This can be mitigated by the Hub warning the user when a 0.5 client attempts to connect and giving him the option to disallow.

Refactor registration API

Currently, registering for an ID, declaring application metadata and declaring supported messages are a single operation. ApplicationsMessagingHighLevelProtocol proposes splitting them to allow clients to change the messages they want to receive.

Backwards compatibility?

OK. We'd have to think about which operation triggers an ivo://votech.org/hub/event/ApplicationRegistered message.

Assign Message IDs

Individual messages will be assigned IDs when they are sent so that responses can be matched up with requests. This is essential if we switch to a completely asynchronous model, and might have other uses too.

Backwards compatibility?

OK.

Generalise metadata

In version 0.5, a client registers with its user-friendly name, which is stored by the hub. Other metadata such as description and logo URL are obtained by sending a message to the client. However, in a fully asynchronous system it will be more difficult for some environments to get this information by messaging. I propose that the former approach is adopted for all metadata, for consistency and ease-of-use. A client would ask the Hub to store a map of key/value pairs that can then be retrieved by other clients. Certain keys (for name, description etc...) would be reserved and their meaning specified by the standard, but clients would be free to define new keys if they needed to.

Backwards compatibility?

OK. The Hub would have to respond to (e.g.) getDescription messages on behalf of v1.0 clients.

Drop Synchronous Messaging

PLASTIC 0.5 allows messages to be sent synchronously or asynchronously. [In fact, only the call from the sender to the hub is asynchronous, and the call from the hub to the recipient is always synchronous.] A completely asynchronous messaging model will be more robust to client failure and long running tasks.

Backwards compatibility?

OK. The Hub would need to do some work accumulating responses for synchronous v0.5 clients.

Change the bootstrap method

The initial connection to the hub is made by reading a file in a well-known location. An alternative has been proposed that uses sockets.

Backwards compatibility?

OK.

Build standard message mtypes with a UCD-like scheme

PLASTIC 0.5 defines message types using IVORNS. The IVORNS are opaque strings that could be resolved in registries. The advantages are: a) Piggybacking the registry authorityId system to get uniqueness while keeping the definition of new messages decentralised. b) It provides a place where the meaning of a message type can be defined. c) Possible machine-use of this information (e.g. locating clients that understand a particular message) However, as yet no messages have actually been registered and so none of these advantages have been exploited. An alternative has been proposed where message types (mtypes) are constructed from a small set of atoms in a UCD-like way. The hope is that this would be more systematic than the IVORN approach, as well as losing us fewer friends in the Registry Working Group.

Backwards compatibility?

Will require a translation module in the Hub, breaking with our philosophy that the Hub doesn't understand (most of) the messages.

Allow clients to annotate message types

Users of PLASTIC 0.5 have been moving to more general message types that tell the recipient what data is available, without telling it what to do with it. The advantage is that it increases interoperability, but the disadvantage is that it reduces clarity for the user. "Messaging annotations" allow a recipient to provide a hint describing what action it will take on receiving a certain message. The sender can then inform the user what the consequences of a particular message will be.

This has been prototyped in PLASTIC by using URI fragments on the message IVORNs.

Note that these "annotations" would not be suitable for all message types, but would be useful for some common use cases.

Backwards compatibility?

OK - I have clients already doing this with v0.5 hubs.

Remove message parameter typing

Currently the parameters passed with messages are strongly typed, using a subset of the types defined by XML-RPC. This has caused some practical difficulties in untyped languages such as Perl, and will also make it tricky to use alternative transport mechanisms such as JSON-RPC that have more limited typing. I propose to drop the typing, since it doesn't really provide any benefit (such as compilation-time error checking).

Backwards compatibility?

Again, will require a translation module in the Hub to add the typing information as messages go from v1.0 clients to v0.5 clients.

Pass message parameters by name.

In PLASTIC 0.5 message parameters are passed as an ordered list. It would be better to pass them as a map/struct of key value pairs. This would provide better clarity about the meaning of a parameter, and make it easier to introduce optional parameters.

Backwards compatibility?

Requires a translation module to add the parameter names for v1.0 clients.

Distinguish message parameters that are passed by reference, rather than by value.

Sometimes it will be useful for an application to know when a parameter is a reference to a resource as it might need to behave differently when the resource is remote or local. This could be the case even if the application doesn't understand the message, but is just passing it on to an application that does. A simple, though hackish, way to do this would be to agree a simple naming scheme when we define message types. For example, we could agree that any parameter beginning with the characters url will be a (you guessed it) URL.

Backwards compatibility?

This relies on change #ParamsByName.

Change the "transport protocols"

PLASTIC 0.5 offers two means of communication: XMLRPC and JavaRMI. Further "transport protocols" have been proposed to make it even easier for clients to use PLASTIC. Conversely, having JavaRMI as a mandatory protocol makes it difficult to write a Hub in anything other than Java. Please vote for one of three possibilities (or leave blank to indicate that you're happy with things as they are):

1. XML-RPC only (less flexible, but unambiguous)
2. XML-RPC mandatory, other protocols optional (flexible, allows innovation, might lead to some clients not talking to some hubs)
3. All protocols optional (let the market decide!)

Voting for 2 or 3 doesn't mean we can't tie things down more in the future when we've seen which protocols are popular.

Backwards compatibility?

OK. Of course, if a Hub supports v0.5 and v1.0 then it isn't going to get the language-independence benefits of this change.