[gst-devel] [KC]lasses proposal #1

[Thomas Vander Stichele]

Hi,

I want to move one so I'm quick to reply ;)

> First of all, please note that I'm talking about the element klass *ONLY*.
> This is primarily visible to people as the tree structure you see when you
> try to select an element in the editor, and should be thought of and
> designed mostly as such.

I have to say I spent quite some time laying out the dirs and I would hate
to have my work go to waste.  I'm talking about dirs here not to piss you 
off Erik, but because the rest of the team doesn't *know* my opinion
about it.  So Erik, skip this section ;)

I still haven't heard any point *against*
the layout worked out by wtay, wingo and me.  It has a few good points.
The main thing to consider here for everyone is that 
a) the only ones who need to care where plugins go in the dir layout is
US, developers on gstreamer.  users don't care, they have classes.
Outside developers don't care, they have their own layout.  The dir layout
we choose is one that makes it easy on US.
b) Re: the ease of use, we want to do this move ONCE.  We all know how
hard it is to move dirs around.  So we NEED something that is SIMPLE and
UNAMBIGUOUS.  Make sure all plugins end up on the same level of file
system hierarchy.
I felt our combined layout as proposed did just yet.
 
But if you want to wait, I will, though reluctantly.  It's bad for gst as
a whole to keep putting off these decisions and I will not fix build
issues anymore until this is resolved.  It just takes too much of my time
waiting.  And I run on a frigging 1 GHz !

Ok, I'll shut up about the dirs after this one comment to make the
point we both agreed on on irc so the rest know : in NO WAY does the class
structuring NEEDS TO BE related to the dir structure.  And in my humble
opinion, either it forces an exact 1 to 1 correlation, or it does not have
any correlation at all.  If it would have a half-baked correlation, it
would just end up giving us two dissimilar half-baked pictures about both
dirs and classes and that would suck.  /me shuts up about dirs now.

> As I told thomasvs, the key here is to discuss the klasses on their own,
> without worrying about any directory hierarchies.  What I'm hoping is that
> something that makes sense will magically appear.  Regardless, we all seem
> to agree that the element klass should be used more broadly (whatever that
> means), so we should settle on a basic structure *first*.

I don't agree they should be settled upon first.  I am hoping for the
magic though ;) In any case, if your basic point is the class structure
should be settled upon first, then let's do this hard and fast.

> Encoder/
> 	Audio/
> 		a52enc
> 		flacenc
> 		gsmenc
> 		lame
> 		mpegaudio

If we're doing this in the classes namespace we should have a clean policy
on how to name them.  let's not call it lame, but mp3.  That's what it
does.  Let's not call it a52enc, because it's already in encoder.  A52 is
the format, and if I understand your layout correctly then that's what is
implied as the third-level.  Correct me if I'm wrong ;)  But either we
name them according to libs, or to format.  No free-form wildgrowing
naming anymore please ;)


> Source/
> 	Device/
> 	File/
> 	Network/

This seems to go against unix philosophy, but I suppose since this is
pointed towards end users, it'll do.  Let's just make sure it actually
separates the plugins; if a plugin works for both file and network
(gnomevfssrc ???) put it in the class layout twice.

> Sink/
> 	Device/
> 		aasink

could aasink handle files too ? shouldn't we split it up somehow ?
Dunno how aalib is structured though.

> Filter/
> 	[everything else, in some other general scheme
> 	 I haven't figured out yet]

Well this is the hard part IMO.  The rest was relatively simple.  This is
also hard because we haven't even started on some of the plugins that
would go here, like an N*M mixer, thought up yesterday.  Get ten sources
and eight sinks, couple it to an autoplug mixer element, set up a matrix,
autoplug it, and bam.  80 element pipeline structure.  (I might have the
math wrong).  Point us, we'll need to add to this as we go along.  Not a
bad thing IMO.

> Now, I've thought about swapping the level of things relative to
> encoder/decoder and audio/video, etc., but I'm not sure that would make
> sense because it would be counter to the other top-level classifications.
> But it would be more intuitive: "I need a [Video] [Decoder] for [MPEG]".
> Then again "I need a [Decoder] for [Video] in [MPEG] format" makes just as
> much sense.

Both make sense to me.  I'd go either way on this.  AFAIC, you may even
have *both* on the top level, so each plugin goes in doubly (it's a
*brain* layout, not an orthogonal implementation layout).

So either of four would work for me :

* Audio/Video as first level, Encoder/Decoder as second level strictly
* Audio/Video as second level, Encoder/Decoder as first level strictly
* The two of these combined
* Also, Audio-Encoder/Audio-Decoder/Video-Encoder/Video-Decoder would work
for me

Just take a pick.

And please, let's all do that.  We need to settle this quickly.

Thomas

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*-                      -*->
When you can't trust yourself
trust someone else
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/