launchpad-dev team mailing list archive

[Leonard Richardson <leonard.richardson@xxxxxxxxxxxxx>]

> 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.)

2. The refactoring succeeds, but some unimportant part of the resulting
data model cannot be made efficient or comprehensible enough to justify
putting it in the web service. For instance, we may know that Launchpad
will run a certain inefficient query very rarely, but if we publish it
we have no control over how often it's run.

In this case, we would proceed with the refactoring and not expose the
less important part. The public data model will be a subset of the
internal data model.

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.

3. The refactoring fails. For complex systems like the HWDB, it may be
possible to design an internal data model _and_ a public data model, but
fundamentally impossible to make the same design serve both purposes. In
this case we would need to retreat from the annotation-based model and
create our own Entry classes. I don't think this is incredibly likely,
but life is complicated, so who knows? We have this option.

Leonard

Attachment: signature.asc
Description: This is a digitally signed message part