[Twisted-Python] deferred folies
hi *, lately i did some dirty Deferred tricks and i just want to know if there is a better way to do what i did. the situation is as follows: a server exposes through pb a "session" object. the client can call on that object "execute" (any number of times) and then "abort" or "end" to end the session. the session is created by calling "new_session" on the remote perspective (after authentication, etc.) now, for a simple get session/execute/end sequence i don't want to write n+1 callbacks (one that waits for new_session and call execute, next one that wait on execute and call next, etc.) so here is what I did (inside a mixin class used in the client): def session(self): return self.server.callRemote("new_session") def execute(self, trans, *args, **kwargs) cb = kwargs.get('callback', None) if self._session: dfr = self.server.callRemote(trans, *args) if cb: dfr.chainDeferred(cb) return dfr else: dfr = self.session() cb = Deferred() dfr.addCallback(self._execute_got_session, trans, cb, *args) return cb def _execute_got_session(self, session, trans, cb, *args): self._session = session return self.execute(trans, *args, callback=cb) that is, from the client the user can just do: d = self.execute("set-foo", 42) d.addCallback(...) and in the callback call .execute again (and be sure to be in the same session) or call end or abort to terminate the session. clear? mm.. what i want to know is if the "cb" trick and chainDeferred call are a dirty hack or if that's the way they are supposed to be used and if there is a better way to do what i do. ciao, federico -- Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org Lasciate che i furetti vengano a me. -- Maria Luisa Benedetta Panzani
On Tue, Sep 30, 2003 at 06:27:43PM +0200, Federico Di Gregorio wrote:
now, for a simple get session/execute/end sequence i don't want to write n+1 callbacks (one that waits for new_session and call execute, next one that wait on execute and call next, etc.) so here is what I did (inside a mixin class used in the client):
If you _really_ want to try avoiding all the callbacks, I think your hack is the wrong way to do it. Use something like twisted.flow's Deferred support: this way, you "yield" when you wait for a Deferred to fire, and then you will be able to get the result synchronously once your function is returned. There's probably an example somewhere in the flow docstrings or examples. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://twistedmatrix.com/users/radix.twistd/
Il mar, 2003-09-30 alle 20:45, Christopher Armstrong ha scritto:
On Tue, Sep 30, 2003 at 06:27:43PM +0200, Federico Di Gregorio wrote:
now, for a simple get session/execute/end sequence i don't want to write n+1 callbacks (one that waits for new_session and call execute, next one that wait on execute and call next, etc.) so here is what I did (inside a mixin class used in the client):
If you _really_ want to try avoiding all the callbacks, I think your hack is the wrong way to do it. Use something like twisted.flow's
no, i don't want to avoid all the callbacks. i just don't want to write three one-line callbacks for a simple call.
Deferred support: this way, you "yield" when you wait for a Deferred to fire, and then you will be able to get the result synchronously once your function is returned. There's probably an example somewhere in the flow docstrings or examples.
but i'll look into flow anyway. :) -- Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org Viviamo in un mondo reale, Ciccio. -- Lucy
participants (2)
-
Christopher Armstrong -
Federico Di Gregorio