[Cubicweb] Service API implementation with ømq

Sylvain Thénault sylvain.thenault at logilab.fr
Wed Feb 29 16:26:18 CET 2012

On 29 février 14:33, Pierre-Yves David wrote:
> > > Pyro is never used repo-side so it does not cache any error here.
> > 
> > As I said, this api is not designed to be used on the repo side.
> Then, it is a major bug. The repo side on such matter the repo side **need** to
> have at least as much capability than the web side. I have multiple instance of
> code used both repo and web side.

You can barely call services from the repo side without having to
go through this repository method (which is there to allow keeping
the client/web side from the data repository side while allowing
access to more exotic stuff without monkey patching or such).
> > > To conclude: I do not buy the "it's designed for Pyro" argument because it's
> > > not used by Pyro in practice.
> > > 
> > > Moreover, manual theorical checking are less robust that pratical use of ømq (meeting the "let's experiment" argument)
> > 
> > You suggest adding zmq to check arguments. Should I buy that?
> No I sugguest using ømq now because we will use ømq in the future.

though we never intended (yet at least) to make it mandatory.
> > And all related to data repository manipulation. Or shall we consider
> > everything as a task?
> Most of cubicweb is about data repository manipulation. It does not mean that
> nothing can be handled outside the primary object use by cubicweb client to
> access data.
> Updating cache for mercurial repository is not the kind of operation that
> should be done in the context of a object meant to allow a web worker to access
> repository data. There is no reason why register a new user couldn't be done in
> another context too. Fetching session and garbage collecting task have nothing
> to do with fetch data to handle http request. etc …
> More decoupling, allows better scaling.

I do agree. Issues lie somewhere else, not here, though.

The services api will go without zmq in a first glance. Then we'll do necessary
stuff to allow more worker processes. Then we may think at making zmq mandatory
and use it systematically for services or other things. If at this point we've 
to change some things to make it work, we'll do it. If it costs us more then 
expected, it will be my fault, fine. But anyway we're still far far away from 
stuff like session/http handling which are in there since almost 10 years ago 
at a time where cubicweb wasn't even named cubicweb and was running behind a 
mod_python front-end.

Sorry but I won't argue more than this.
Sylvain Thénault, LOGILAB, Paris ( - Toulouse (
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org

More information about the Cubicweb mailing list