launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Wed, Feb 22, 2012 at 6:00 AM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12-02-20 11:55 PM, Robert Collins wrote:
>> So, going back at least 18 months, maybe more, there has been a
>> long slow-running conversation amongst us about what we render
>> were, with different projects choosing different answers.
>>
>> I think we have enough data now, that we can consolidate on a good
>> default answer and ask that everyone pick that answers *by
>> default* with variation needing to be experiments - explicit
>> decisions to learn something new.
>>
>> tl;dr: lets: * render searchable content on server side and client
>> side using a common template language * render the forms needed to
>> file a bug server side and optionally client side * render all
>> other forms exclusively client side and have them communicate
>> exclusively via the API
>
> I think that this approach makes sense.  The current API is not
> roundtrip-efficient for multiple-item listings, but forms are usually
> related to a small number of items, so this should not be a problem.
>
> You didn't specify that the API must be used when rendering searchable
> content on the client side.  The JSONCache is roundtrip-efficient for
> this purpose, and can also deliver identical data to client-side and
> server-side templates, so I think we should prefer it for now.
>
> If we want to use the API for client-side rendering of things like bug
> and branch listings, I think we will need to change the API to make it
> roundtrip-efficient, and find a way to ensure that identical data is
> presented to client-side and server-side renderers.

So, the API is *capable* of being round trip efficient for any use we
would make of it in a web page. Some of our 'magic' glue however will
be in the way and in the short term is best avoided. E.g. a collection
of nested dicts can be trivially returned by an API call; a collection
of Bug objects will return only the Bug object representations
themselves.

I don't think we need to change the API to use it, but I think we will
want to change it to make using it effectively as easy as possible. If
anything, I think we want to stop returning precanned fully-populated
objects and start returning the relevant data from given calls.

There are, relatedly, a number of big picture refactorings we could do
which may or may not help the API chattiness for e.g. launchpadlib,
but I think they are all aiming at generic optimisation, not the
rather specific stuff that we currently do in the view cache, and
which the LP API is *entirely capable* of doing as well.

-Rob