On Sun, 2008-07-20 at 21:42 +0200, Dirk Meyer wrote: > > The state engine now uses coroutines, it _should_ be safe to remove > > the state decorator. But it _could_ break code depending on it.
I think changing API and/or behaviours in popcorn isn't going to affect a lot of people. Probably just us. > backend to change the state. This is the old code I don't like at > all. IMHO backend.open() should return an InProgress object that will > be called when the backend is open. Since our backends are based on > external processes some kind of state machine would be required at > this point. I think any state machine should be pushed into the backend, because that is probably going to be backend-specific. So I think I agree with you: backends should be returning InProgress objects for any action that returns a deferred result. In most cases, the generic Player could just return that InProgress back to the caller. I wonder if the generic player is really even needed. If we define an interface that all backends must conform to, then the user could interact with them directly (and just rely on duck-typing when needed). It's difficult to say if that's going to work in practice. If we end up duplicating a lot of code, the generic player wrapper does make a lot of sense then. Jason. ------------------------------------------------------------------------- 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
