[PATCH 16/51] settings: Add Django REST framework to the project

Damien Lespiau damien.lespiau at intel.com
Tue Sep 22 23:09:44 AEST 2015


On Tue, Sep 22, 2015 at 01:19:25AM +0100, Finucane, Stephen wrote:
> > Let's try to do have a more modern approach to this web thing. Having a
> > separate API returning some JSON ensures a nice split between data and
> > UI. This API can be both used withing the HTML pages, loading/updating
> > data with AJAX, and from any other kind of client (say, it could replace
> > the XML-RPC API patchwork currently has).
> > 
> > But for now, let's experiment on Series.
> > 
> > Signed-off-by: Damien Lespiau <damien.lespiau at intel.com>
> -1 This series revolves around adding support for series parsing: this
> patch (and subsequent, related patches) focuses on adding a different,
> large and currently unrequired feature. This secondary feature should
> be done in a different series, as suggested previously:
>   https://lists.ozlabs.org/pipermail/patchwork/2015-August/001417.html

Doing so in a different series would mean redoing the client-side part
of Series. If we can agree to move to a REST API long term, I think
having the REST API as a dependency for Series fine.

> Addressing your points from that previous mail:
> > Of one of the main thing is being able to re-use the API entry points
> > from the web page itself (say using jquery's ajax). That makes the UI
> > much nicer to use and reduces what the server needs to do (no full page
> > reloads).
> AJAX is great, but it's not necessary for series support. I'm all for
> responsive applications (in all senses), but I have yet to see a
> complaint about patchwork's resource demands nor a user requesting the
> functionality that AJAX would provide. If you personally think
> patchwork then by all means, make it happen but do so in another
> series.

I'd rather not spend time spinning patches if the end goal is the same.

> > It also forces us to think in terms of objects and methods and have a
> > clear separation between the backend and frontend(s).
> What does this give us, besides slightly nicer "architecture"? The end
> user won't see this, but they will see the bugs and design oversights
> that will inevitably be present. APIs are hard work and once they're
> out there there's no going back: we want to make sure the one we
> implement is "right". This is something that needs to be discussed in
> its own thread.

I'm fine with discussing the API anywhere. I'm not saying that it's
perfect and in fact I've already done a few adjustments locally. There
are ways to mature an API before declaring it stable, especially when
the number of users is rather small and we have pwclient for the stable

> > Right now the
> > XML-RPC API feels like a bunch of disjointed functions. We also mix the
> > views with API and have a number of "random" API entry points as POSTS
> > requests on view.
> Now this is a real issue. However, why not fix this in another series
> rather than trying to replace something that is well working but
> perhaps not as clean as it could be? The XML-RPC API may need some
> work but there's nothing fundamentally wrong with it (RPC is not dead:
> it's just out of fashion).

> In summary, while I understand what you're trying I think you're going
> about it the wrong way. There may be some valid reasons for using
> REST, but we are currently able to do patch support with XML-RPC and
> we can sure do series support the same way :)


1/ Are you happy with the idea of moving to a REST API instead of

If No, that makes things easy, I'll just fork.

2/ If yes, then we need a path to make it happen. I didn't think that
doing so for a new feature was out of line. As always, everything stays
the same, all the XML-RPC API is still there and pwclient works. We can
still have the API discussion, of course.

3/ On top of that, I don't really have the time to redo things
endlessly. I already have the impression that the re-design series is
being bikeshedded.

I have the growing feeling that I'll need to fork the project to reach
my goals in a bounded time. The re-design part is already 1 year old for


More information about the Patchwork mailing list