Re: Malone UI changes

[Ian Jackson <ian@xxxxxxxxxxxxxxxxxxxxxxxx>]

Christian Robottom Reis writes ("Re: Malone UI changes"):
> There will be a programmatic interface and a client library; we're not
> sure what protocol it will use, but isn't that irrelevant?

I think this is the wrong design.

Since in a deployed application the client library can't be updated in
the field anyway, there has to be a stable protocol to LP.  That means
that the protocol needs to be kept stable and reasonably simple.  With
such a stable and reasonable interface there will be no need for a
special-purpose library.

We (people writing code which needs to talk to LP) would prefer not to
have to gain a dependency on a complicated library.  The code we write
may not be in the language you choose to provide, and since this
library is little more than a layer of glue it would be silly to put
another layer of glue on top of it.

Our code may need to run in environments where the proposed LP access
library is not available and where it is hard to port.  Eg, it will
often need to run on earlier versions of Ubuntu and it may even
sometimes need to run on non-Ubuntu machines or even non-UNIX
machines.

The point about not updating the library in the field is particularly
important: you cannot assume that you can push new versions of the
proposed library to our deployments at the same time as you change
Launchpad.  In practice in some situations it will be difficult to
push out new versions at all.

Therefore I think the interface to replace screenscrapers should be
defined in terms of https GET and POST, with some conventional
and widely-supported standard encodings of the parameters and results
(eg, form query arguments and plain text output, as if for a web
browser).

That would allow very quick and easy development of new automation
tools since all modern languages and environments can support making
https GET and POST requests and parsing plain text files.

XMLRPC sounds nice but in principle but in practice XML often invites
additional complexity and XML parsers are of course nontrivial
programs which have substantial costs (in terms of performance,
operational demands, maintenance, security support, interfacing to
their callers, etc.)

Ian.