Jason Tackaberry wrote:
> 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.
I agree.
> 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.
We need at least a generic entry point. I don't care about what player
to use, kaa.popcorn knows it better based on FOURCC and extension. And
kaa.popcorn can also try different player. This means a generic player
API needs at least an open() call to return the backend that should be
used.
> If we end up duplicating a lot of code, the generic player wrapper
> does make a lot of sense then.
IMHO we may need some sort of state machine in all backends.
Dischi
--
"There's no point in being grown up if you can't be childish sometimes."
[Dr. Who]
-------------------------------------------------------------------------
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
