[gst-devel] Request for ideas: decoupled elements

[Andy Wingo]

On Tue, 30 Sep 2003, in7y118 at public.uni-hamburg.de wrote:

> My idea was always that elements _without_ schedulers are a special case of 
> elements. No. Elements _with_ schedulers are a special case of elements. Our 
> whole object model needs turning around :)

Hm. My own thoughts couldn't make that leap but I see how that's a nice
solution... I'm cringing to think what it would mean for existing plugins, but
let's consider the object model that you propose.

> GstElement            - base element, doesn't know about schedulers
> + GstSchedulerElement - basic scheduler-aware element

Maybe...

> | + GstChainElement   - chainbased
> | + GstGetElement (?) - getbased (could be the same as ChainElement?)
> | + GstLoopElement    - loopbased

I wouldn't have these as subclasses. I think this degree of subclassing makes
GStreamer less flexible, and doesn't really solve any problems. For instance, in
soundscrape I plan to support multiple algorithms based on which input pads are
connected. In that case an element might be a get element, or maybe a chain, or
maybe a loop -- it depends at runtime. The kind of scheduling depends on what
pads you have, which can change at runtime.

I think that's the general principle with this level of refactoring: let
sleeping dogs lie ;) Maybe scheduled elements are better off as a subclass, but
we'd need to look at the benefits this would give us. Sometimes this sort of
change is better done in a non-OO way (with flags and sched-private data like we
have). Again, I'm unqualified ;)

Regards,

wingo.