[Cubicweb] Service API implementation with ømq

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

On 29 février 12:53, Pierre-Yves David wrote:
> On Wed, Feb 29, 2012 at 11:41:48AM +0100, Sylvain Thénault wrote:
> > On 28 février 17:05, Pierre-Yves David wrote:
> > > This goes in the wrong direction:
> > > 
> > > :using standard python call passing standard python reference:
> > > 
> > >     Not restricting usage of this API means that people will use it
> > >     unrestricted. If people use it unrestricted it'll be painful to move toward
> > >     more distributed approach.
> > 
> > What are you afraid of? IMO this is already "restricted" since this
> > API is designed to be called through the db-api (so not from the repo 
> > side btw), so arguments should be expected go through pyro/zmq which
> > limits the notion of "reference". If that would make you feel better,
> > we can ensure that arguments are python base types (and doesn't expect
> > on reference passing side effect, though that's harder to check without
> > limiting to unmutable types, which we probably don't want)
> 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.
> Pyro is seldomly used any way. How much web only instance are running in
> production? I do not believe this is really tested for most cubicweb based
> code.
> Pyro add several magic layer that make it hard to follow what's going on for
> fellow cubicweb developper which never bent over Pyro

We do use pyro based db-api, though you're right not for web ui communication.
> 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?

> > > :inside the main repository code and thread:
> > > 
> > >     This code does not belong here:
> > > 
> > >     Adding any logic code to repository is a bad idea. The logic we are adding
> > >     here is related to "a server processing tasks" not "data repository".
> > 
> > No. We're not writing a tasks manager here, simply providing a generic
> > way to call services that should be run on the repository side.
> > For instance I do intend to rewrite some stuff which is currently written has
> > repository methods such as "register_user"/"find_users" as regular services.
> > The aim is to make the repository extensible without having to monkey patch
> > it (we've a bunch of use case for this).
> Yes we does. We are running task here. Some are light, some are heavy but all are
> task (or at least most).

And all related to data repository manipulation. Or shall we consider
everything as a task?

> If you suggest mixin simple callbak and complexe task all together, I'm ever
> more opposed. Mixin stuff related to repo and unrelated to repo is a bad idea
> too.
> Note that even simplest repo call are processed in a thread by Pyro.

I don't get the point here.

> > >     For the same reason, repository have no reason to handle Thread
> > >     spawning
> > 
> > I do agree with this point though we already do that, and we may change that
> > to zmq or whatever at some point.
> It's not because we already do it that we should keep doing it. Adding more stuff be be cleaned up later *is a bad idea*[1].
Though I still fail to see what'll have to be cleaned up later. 

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