On Wed, Feb 22, 2012 at 6:00 AM, Aaron Bentley <aa...@canonical.com> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
