* Christopher Armstrong <[EMAIL PROTECTED]> [2008-03-06 11:29:56 -0500]:

> Ok then, let's consider your approach. Let's say we have a multi-shot
> deferred object. How does our application code get a reference to it?
> How does the framework code get hooked up to the ultimate resource
> object that wants to handle this streaming data?

The same way it would get access to a one-shot Deferred.

> The point of these questions is to indicate to you that you need to
> figure out how to do this "hooking up" anyway, regardless of whether
> you have a MultiDeferred, and thus a new interface (whether formalized
> in terms of an Interface) must be created.

My understanding was that the main advantage of Deferred was to provide
a standard implementation of chaining callbacks together; presumably a
"MultiDeferred" would also provide this functionality, while persisting
the chain over multiple invocations.

It doesn't seem like that's terribly useful in this particular case, but
it might be useful elsewhere.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web

Reply via email to