[Cubicweb] Service API implementation with ømq
sylvain.thenault at logilab.fr
Wed Feb 29 11:41:48 CET 2012
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)
> :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).
> 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.
> :handling Thread spawn by hand at the same place than the remaining logic:
> Dispatching tasks and running tasks are two different things. We'll
> probably use efficient third party for the dispatching part one day. Not
> entangling the two logics now is a later win.
Same answer as above.
> Let's not release anything that will later need to be changed to scope with our
> current goal. Let's enforce ømq limitation **now** so we do not need to handle
> backward compatibility later. Let's open the new ømq way on a new feature with
> no user yet. Let's do it right the first time so we do not need to fix it
I disagree with your conclusion. And i don't want this service api to
depends on zmq (yet, at least).
Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (09.54.03.55.76)
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