launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Thu, May 20, 2010 at 5:14 AM, Leonard Richardson
<leonard.richardson@xxxxxxxxxxxxx> wrote:
>
>> And there is the issue I think: what makes a great web services API is
>> fundamentally different to what makes a great in-app-server API. The
>> latency and bandwidth constraints are radically different.
>
> I think one of three things will happen when we try refactoring a given
> part of the data model.
>
> 1. It works fine. There is no fundamental reason why the internal API
> has to be different from the public API. For small things like
> setStatus, I think we will find almost all the time that we can refactor
> the code into one superior API. (Apart from backwards compatibility
> problems.)

I'd love to be proved wrong. I don't see how to reconcile 'feels like
python', 'do one thing well' methods and 'is not potato programming'.
If any of those three constraints are lifted, I can see many
interesting ways of dealing with latency such as microlanguages to run
on the server side.

As a for instance, how do we make 'composePublicURL' work correctly:
it has to do a round trip today; its invalidated if any of the fields
used in generating the name have been altered but the object not
saved, and auto-saving on every attribute implies a very different
model to in-app-server programming where you can assemble a set of
changes within a transaction.

> We know we need special features to deal with the greater latency of the
> web service, but I'm not convinced these features have anything to do
> with specific data models. The ability to group objects into ad hoc
> collections and perform operations on the collection (or however we want
> to implement this) can be implemented in lazr.restful. We shouldn't need
> to implement this ability separately for bugs and for people.

I'm not claiming that dealing with the two different environments is a
matter of data model. I'm claiming its a whole-programming-stack
problem. We've got /some/ answers to this in bzr, and we have a much
simpler model we're dealing with.

I don't intend to put you on the spot - that is, if you don't have an
answer, its fine. But it would comfort me to know that some of the
following are intended to be addressed:
 - the transaction vs non-transactional model:
 * for instance: in LPAPI's, how do you create a set of objects that
temporarily violate DB constraints, which appserver code can do
easily. As a concrete example, rename two objects A and B to be B and
A, safely
 * or call methods on altered objects without saving them (saving them
means you can't check you have achieved what you wanted to achieve)
 * LPAPI's cannot do repeated reads, so any appserver code that
depends on that can't really be ported to LPAPI's.
 - speed
  * It takes 13 seconds to log into launchpad, find out that there are
some pending merges for bzr and quit hydrazine again.
     This may not seem like a long time, but really - it is, for
something that should be a single HTTP request [I say that because in
other web services API's *it is* a single HTTP request].

-Rob