[Cubicweb] Service API implementation with ømq
pierre-yves.david at logilab.fr
Wed Feb 29 12:53:05 CET 2012
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.
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
Pyro add several magic layer that make it hard to follow what's going on for
fellow cubicweb developper which never bent over Pyro
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)
> > :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).
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
Note that even simplest repo call are processed in a thread by Pyro.
> > 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*.
 say the guy spending a week to clean up http handling to the guy spending a
week to clean up session handling.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Digital signature
More information about the Cubicweb