Ideas for changes to the Plastic API

...or what I hate about Plastic 0.5

Please use this page to log suggestions for things you'd like to change in the current spec. Be as bold as you like - this is for ideas that could go into a future release that isn't compatible with what we have at the moment. Don't worry if the ideas are mutually exclusive!

A. Plastic API

1. Make registration a two step process

I think acquiring a Plastic ID (preparing to make requests) and registering for service (preparing to accept requests) are logically separate operations. So how about replacing

          URI registerRMI( String name, List messages,
                           PlasticListener listener )
          URI registerXMLRPC( String name, List messages, URL callback );
          URI registerNoCallBack();

with

          URI register( String name );
          void serveRMI( URI plid, List messages, PlasticListener listener );
          void serveXMLRPC( URI plid, List messages, URL callback );

(followed by s/UR[IL]/String/g as above)

Reason

Apart from (what I claim is) improved conceptual tidiness, this has the advantage that the application can modify the list of messages it supports during its PLASTIC lifetime, e.g. as a consequence of user choices, by calling one of these methods with a modified list.

Suggested by

Mark

Compatible with Plastic 0.5?

No, but wouldn't break existing apps.

Comments

---

2. Stick to xml-rpc types in the API

Instead of

URI plid = hub.registerXMLRPC(java.lang.String name,
                                 java.util.List<java.net.URI> supportedMessages,
                                 java.net.URL callBackURL)

have

String plid = hub.registerXMLRPC(java.lang.String name,
                                 java.util.List<String> supportedMessages,
                                 String callBackURL)

Reason(s)

Less confusing for non-Java developers. Easier to write a hub. Plastic message arguments are plain xml-rpc types, so you often find yourself having to convert between (e.g.) a URI and a String. Plastic API doesn't use particularly rich types so there's little to be gained from using java types.

Compatible with Plastic 0.5?

No - perform method would have to change.

Suggested by

Mark Seconded by John

Comments

---

3. Prune the PlasticHubListener^? interface

Prune the PlasticHubListener^? interface a bit by replacing some of the methods (getMessageRegisteredIds(), getName(), getRegisteredIds(), getUnderstoodMessages()) with normal PLASTIC messages which hub implementations are either required or strongly encouraged to support.

Prune the PlasticHubListener^? interface even further by collapsing all the request* methods into one or two.

Reason

The main motivation for this is to keep the hub small as a matter of principle, and to provide a precedent for other useful-but-not-absolutely-essential hub functionality that we've not yet thought of to be provided via messages rather than interface changes (since the former are much easier to introduce without causing version problems).

Suggested by

Mark

Compatible with Plastic 0.5?

No.

Comments

My own preference is to keep the absolutely essential stuff in the API so at least we can define a minimum amount of functionality that the client can expect. Otherwise each client is going to have to do quite a lot of if-then-elsing. Defining what is absolutely essential is subjective (!), but my vote is (currently) for:

getHubId <- we could dispense with this and put the Id into the .plastic file getRegisteredIds + the register and request methods.

I feel we can lose getMessageRegisteredIds (ugly name, anyway) and getName (and instead make it strongly recommended that clients support the getName message). One argument against losing getName (in fact, the reason for introducing it in the first place), is the existence of clients such as scripting environments that can't be messaged. We could deal with this by using the fact that applications do register with their human readable name, and propagate it in the ApplicationRegistered^? message for anyone who wants it.<- Mark has pointed out that this won't work for scripting environments that registered before our app.

I think that encouraging other hub operations to be done via messaging is probably a good idea. That way those who want to implement Pierre's "shutyourselfdown" message can. It might also allow us to address Richard's concerns. -- JohnTaylor - 18 Jul 2006

---

4. Change the "request" methods

Change the "request" methods to send to a single app, or broadcast to everyone.

I was thinking rather of replacing the requestToSubset* methods. I don't think anyone is using them to send to more than one app at once - I imagine most of us are indeed wrapping them with a method that takes a single recipient.

Reason

The predominant use case that seems to be emerging is one of point-to-point communication, and it's annoying to have to create an array of one receiver and then extract the single returned value from a Map.

Suggested by

Compatible with Plastic 0.5?

No - but can ease the pain by merely deprecating the requestToSubset methods initially.

Comments

I'd resist this if it looked like it was going to clutter up the interface further (e.g. double the number of request* methods again). It's easy for any client application (or plastic toolkit for client-side use) to write a short function built on top of a requestToSubset call to do this. --Main.MarkTaylor

5. How do we deal with versioning?

Should clients declare their version number when they register, so that hubs know in advance how to speak to them? Hubs could then reject (somehow) registrations they didn't understand. Should we go for some notion of version ordering? My initial feeling is to follow the SOAP spec and say no....understanding version n doesn't mean I understand version n-1.

Reason

We haven't defined what we mean by version yet. At the moment the hub can only determine the version of plastic a client supports by sending it a message. It really needs to know the version to do that!

Suggested by

John

Compatible with Plastic 0.5?

No.

Comments

---

6. Generalise the application metadata

Currently, an application registers with its name. Generalise this from a string to a struct, with keys for "well-known" attributes such as human-readable name, description, ivorn, iconUrl, plastic version etc. Instead of getName, have a more general method that gets the all the metadata about an app (or all the metadata about all registered apps?).

Reason

The metadata is then extendible.

Suggested by

John/Mark

Compatible with Plastic 0.5?

No

Comments

---

7. Security

There is currently little security provided by PLASTIC. XML-RPC connections are in practice somewhat protected by the fact that the hub's XML-RPC URL has to be read from the .plastic file (though dependent on the hub implementation it may or may not be guessable). The same doesn't really apply to RMI, since although according to the spec you have to look in the .plastic file for the RMI port, in practice it's always(?) the well-known RMI port 1099. In any case the .plastic file is regenerated each time the hub starts, with default permissions, which are quite likely to include public read access to anyone with read access to the user's home disk.

There are two separate issues: firstly, the hub does not check the identity of a client's request, so for instance client A can unregister client B without B consenting or even knowing (is this a feature?). Secondly, anyone (not necessarily on the local host) can connect to the hub. Both these are probably soluble by mechanisms involving passing cookies around.

We've probably got a little breathing space before we can expect hordes of Bulgarian script kiddies to launch PLASTIC-based attacks on the world's servers, but if PLASTIC is going to become as widely used as we hope, I don't think we can ignore this indefinitely.

Suggested by

Mark

Compatible with Plastic 0.5?

To a degree. If the .plastic file includes a secret cookie, then this could be introduced as a parameter of new commands. But it would be better to make the cookie argument (or, better, a client-specific derived key assigned by the hub at registration) a parameter of the hub request() methods themselves (not compatible).

Comments

---

8. Exceptions

Currently there is no facility for a PLASTIC message to generate an error status. Since both RMI and XML-RPC would support this behaviour, I don't see why we shouldn't permit them.

Reason

An exception message allows the caller, rather than the recipient, of a request to decide what to do about a failure (tell the user why it failed, try again, ignore, ...). This is usually a better way around to do things.

Suggested by

Mark

Compatible with Plastic 0.5?

Not with the letter of the law, but requests throwing exceptions probably wouldn't cause many things to break.

Comments

---

B. Messages

Namespace

The 'standard' messages are currently called things like "ivo://votech.org/test/echo". Since this is supposed to be an IVORN, and hence in principle and perhaps at some point in fact a key in the Registry, I'd say it's being a bit cavalier with the namespace - someone else might decide they want to give something entirely unrelated to PLASTIC the same IVORN. Probably a better name would be "ivo://votech.org/plastic/test/echo" or "ivo://plastic.votech.org/test/echo". Since the messages are quite bedded in now, changing this may not be a realistic prospect for existing messages however. -- MarkTaylor - 07 Aug 2006

C. General

File sharing

Institute some mechanism for sharing files.

Reason

The current pattern is that application receive a loadFromUrl message and make their own on-disk or in-memory copy of the contents of the URL. This is inefficient and would be better done using shared resources managed by the hub.

Suggested by

Richard

Compatible with Plastic 0.5?

Comments

-- JohnTaylor - 18 Jul 2006