Hi, first of all, I guess you have a script testing all this. Can you add it to the base/test directory please.
Jason Tackaberry wrote: > This new protocol is so that one can pass arbitrary objects within kaa where > an > InProgress is supported, and it will be translated or coerced to an > InProgress. > One example is Signal (which is the only object that has an __inprogress__ > implemented.) So you can now pass signals directly to InProgress(Any|All) > and can now yield signals in coroutines. Now that I see the code, I'm not sure it is a good idea to call __inprogress__ in the coroutine. As we talked about, you can not "return" a Signal anymore. And the new inprogress() function gives me anything I wanted with InProgressCallback and the signal support. I propose to remove the sepcial handling again. So | yield signals will "return" the signal. If you want to wait use | yield inprogress(signal) It is just one word more on the caller side and IMHO it makes the code cleaner because the caller states that this line does not return but uses an InProgress. Example: | if beaconquery.not_finished(): | yield beaconquery What happens? Does it return the unfinished query or does it wait? You can not be sure unless you look at the code of beaconquery. On the other hand if you see | if beaconquery.not_finished(): | yield inprogress(beaconquery) you know what happens. Dischi -- The world is full of willing people -- some willing to work and some willing to let them. - Robert Frost. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
