[gst-devel] directories vs classes

[Paul Flood]

Ello y'all,

This being my first post to this list let me make a few disclaimers:
-I am not a programmer, if my ideas are junk - please file them
appropriately
-I am not a linux user (yes, I use that demon called windows).  So, if my
comments are misguided, please ignore them.
-I am not a developer.  I won't change one line of code. So don't fret that
I'm going to mess everything up.  Omega sees to it that I'm not allowed to
do that 8-]

However, I do think I have something to contribute regarding the current
logjam we seem to find ourselves in.

It appears to me that our crux of the difficulty is that we are trying to
incorporate both a class hierarchy and directory structure into one
organism.  While these two are crucially related, they are not the same
thing.  The classes indicate 'who does what' while the directories designate
'what goes where'.  While these two need to be closely related, they do not
have the same goals.

A class hierarchy seeks to group objects into a rational system that allows
people to see the relationship between objects from an abstract perspective.
Let me rephrase that.  We group things into classes so that when I need a
specific plugin, I can find it with relative simplicity.  It should be
somewhat intuitive and relatively easy to discover.

A directory structure's goal is to keep everything in its place.  That goal
being two pronged. First, we need to assign it a place and second, we need
to make sure the right stuff goes in the right spot.  When trying to
determine where to put everything, our goals are similar to that of the
class hierarchy, but decidedly different.  We want the directory structure
to be somewhat intuitive and organized, but for different reasons.  Here we
seek a structure that protects our own sanity.  A structure to help us as we
draft releases.  One that will help the tasks of maintenance and
distribution.

While a directory structure should be similar to the class structure, it
should not mirror it.  The directory tree needs to be relatively flat.  We
have already found significant obstacles trying to draft structures that are
more than a few layers deep.  This structure should display what we have
relatively close the surface.  This makes things somewhat predictable for
the developers that use this system.

The class system can function in a very different way.  While a directory
only has one home for each part, a class system can have as many pointers in
as many places as we deem prudent.  The class system has to be intuitive for
many different people.  IMHO the best way to accomplish this is to have
multiple pointers for the same object within the structure.  I like Erik's
proposed structure, but he demonstrates the crux of the issue at the end of
his mail...both schemes make sense.  So I say, use both (i.e. the first
level would be 'by type' (audio/video) or 'by function' (encoder/decoder)).
Don't try to force every plugin into one little cubby-hole.  If an element
seems to overlap into several, point at it from each logical area.  To a
large degree, pointers are free.

I understand that we don't want each substructure to include every plug-in,
that defeats the entire purpose of having a class structure.  But let's
recognize that not every element fits cleanly into our scheme.  That isn't
because our scheme is bad.  It is because we are dealing with complex
elements.

I make no proposals about these systems.  I am not familiar enough with them
to that.  I am seeking to highlight the common ground.  I state these
positions in order to spur us on in development.  Perhaps these are all
givens, the premises upon which we were already operating.  Perhaps the
ideas have no merit in our particular circumstances.  I leave that to you.
You are the developers.  You must plot the course that GStreamer will
follow.

Humbly,
Chief Highwater
paul at temple-baptist.com