The XML/HTTP interface is modelled on the existing PluginInterface (look at the Azureus source, org.gudy.azureus2.plugins...) with a simple remoting layer on top (the remote layer is basically in org.gudy2.azureus.pluginsimpl.remote - the remote equivalents of the local plugin interfaces are prefixed with "RP" - e.g. RPPluginInterface is the remote version of PluginInterface). In the remote code you can see what methods are actually available remotely - either the RP<X> object doesn't exist (in which case the entire interface isn't supported) or methods within it invoke "notSupported".

The XML serialiser simply takes the RP objects and serialises them using reflection. Any non-transient fields are serialised to the XML stream. Objects are serialised by using an <OBJECT> tag with an <_objectid> entry giving the object a unique id. That is, all objects have unique ids.

A client gets a "connection" to Azureus when it initially makes a request to it. This connection identifier must be used in all subsequent calls.

Each request must have a unique "request id".

The request message has a METHOD tag (indicating what method to call), an OBJECT tag (for all calls apart from the first one) and optional PARAMS. The response is either the result of the call (for example, a further object) or an tag.

Arrays are passed as ENTRY tags with an "index" attribute.

Requests must be HTTP POSTed in the content. The target for the post is that of the host:port of the plugin plus "/process.cgi". For example, a loopback connection can be addressed via "http://127.0.0.1:6884/process.cgi".

Its a very simple interface I'm afraid, knocked up in a couple of hours, and it shows :)

Here's an example:

Here's an example of a request with parameters:

good luck

Paul