On Sun, 2008-02-17 at 21:37 +0100, Duncan Webb wrote:
> Sorry being think again, I don't get it.
>
> If a rpc method in the server is being called from a client why should I
> need to fix another method that is not obviously being used either by
> the server and definitely not by the client?
I think we have been getting our wires crossed for the last several
emails.
As I understand it, this is what's happening:
1. You're doing an RPC call
2. The remote end returns what I assume is a TvProgram object.
3. You are yielding the result, the TvProgram object, in a
coroutine
4. The coroutine wrapper checks this result to see if it's
NotFinished (in order to decide if the coroutine needs to be
resumed later)
5. As a result of this check, it implicitly calls TvProgram.__cmp__
6. TvProgram.__cmp__ expects only to be compared with other
TvProgram objects, and as a result blindly accesses the other
object's title attribute
7. NotFinished does not have a title attribute. An exception is
raised.
I think this is unambiguously a bug with TvProgram.__cmp__. However I
have updated the coroutine code to check the object ids rather than
comparing them, so __cmp__ will be avoided. This is better anyway.
> I must admit that I'm starting to think that kaa.coroutines are more
> trouble than they are worth.
They're quite convenient things, I find. I'm still not certain you're
seeing them properly. But in they end, coroutines are just syntactic
sugar. If you prefer, you can always connect result handlers to
InProgress objects and break out the coroutine into smaller, regular
functions, and just chain them together into a state machine.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
