[gst-devel] plugin splitoff

[David I. Lehn]

* Thomas Vander Stichele <thomas at urgent.rug.ac.be> [20011216 17:13]:
> As soon as we import this tarball in cvs as a plugins module, we'll put
> the plumbing back in.
> 

Is CVS module going to be called 'plugins' and own/ext/etc directly
under that?  Ok, but tarball should be gstreamer-plugins...tar.gz.


> If anyone cares I can delve deeper in the how and why and why it's
> actually fancy when we start incorporating unstable libs, but not
> right now.
> 

How about now?  We should try to use system shared libs as much as
possible.  I guess if we need to track particular versions of something
for whatever reason we can deviate, but hopefully as just a temporary
measure.


> plugins

This is odd... I can't think of what to complain about on this one. ;)


> plugins/own

Kind of trivial complaint here.. 'own' sounds lame to me.  Why not
'plugins/gst/'?  (indep/ too long, int/ would confuse people that these
not meant for user use... I like gst/ the best)


> plugins/own/mono2stereo
> plugins/own/stereo2mono

Already had comments on merging these.  Perhaps in the future it could
move to a generic N-1 1-N plugin.  Not sure what audio terminology is
for that.  crossbar mixer or something: xbarmixer.  Maybe these are just
best left as often used custom versions.


> plugins/ext/dvdread

Any reason to call it dvdread vs just dvd?  Yeah it happens to be using
libdvdread right now but we might add other stuff like dvdnav or
whatever in there too.  Just 'dvd' would cover it all and IMHO be just
as clear.


> plugins/system

Whoa, what is this?  Too many characters.  Most of us are unix users!
Let's try just 'plugins/sys/' ;)

If I understand what you mean from the wiki, anything that accesses
platform specific hardware or drivers goes here?

That would cover arguably (some in ext now): 1394, aalib(?), esd,
cdparanoia, sdl, xmms, gnomevfs(?), alsa, arts, artsd, dvd, oss, dv, ...
Starts to look like list of anything with a src or sink.

Or does 'sys' just mean plugins that access more raw APIs vs
intermediate libraries?  In which case the above list is mostly bogus.
Kind of a hard call isn't it?  It's not like we're actually flipping
hardware bits in any of these plugins.  How do you determine platform
specific stuff?

Without really understanding what 'system' means I'd almost suggest that
just anything that links to other libs be thrown in ext/ and drop the
system/ thing.  I guess I need a better explaination.


> plugins/own-libs

Again, I'd prefer some name like 'plugins/gst-libs'.  But why have the
'own' part at all?  Why not just 'plugins/libs'?


> plugins/doc
> plugins/doc/filterstamp
> plugins/doc/capture

Are these really docs?  More like 'plugins/misc'.


> plugins/unstable-libs
> plugins/unstable-libs/mplib
> plugins/unstable-libs/avifile
> 

Hmm?  What does 'unstable' mean?  Why not just 'ext-libs'?

Overall reorg not too bad.  I guess.  Though I still think a CML2ish
build setup and mostly everything except gstplay and the editor in one
tarball would do just fine.

So debs/rpms for the plugins could be something like the following with
gstreamer prefix and some renaming of what you have:

-gst (vs -own, with all the indep plugins)
for p in ext/: -p
-libs
-ext-libs (?) (vs -unstable-libs?)
-misc (vs -doc, since -docs should really be for the main docs)

-dave
-- 
David I. Lehn <dlehn at vt.edu>  | http://www.lehn.org/~dlehn/
Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA