[gst-devel] plugins

[Christian Fredrik Kalager Schaller]

Hi,
Well personally I am not in favour of splitting up the modules before
the next release, but when we do split (before or after the 0.3.0
release) I think this proposal makes sense.

Christian

On Sun, 2001-12-09 at 11:08, Thomas Vander Stichele wrote:
> Hi everyone,
> 
> people seem to agree on the fact that we need to split off the plugins
> from the core in order to make the build more manageable.
> People also haven't agreed yet on a good way to split up plugins.
> 
> I think that if we're not talking about it we have no hope of an agreement
> ;)
> So we had people who wanted no subleveling at all on the one side, and
> people like me (I might even have been alone ;) ) who like deep nesting.
> 
> So I thought about it some more and I think I might have an idea that can
> more or less please us all.
> 
> I think a good division should make it easier for end users and "light"
> developers who only want to work on one type of plugin.  It should be easy
> for people to install most of what they would consider "core gstreamer",
> the things they don't want to touch, and get the rest from CVS.
> 
> Case in point : I like to work on mixing, and only that.  So I really
> don't care about all of the video plugins (from a development standpoint),
> and I also don't care about all the audio plugins that interface with
> actual file types.  I'd just like that to be done automagically.  Right
> now, I have to download and compile all of gstreamer, which makes the
> threshold for me to dive in extremely high.
> You can easily think of other developer scenario's.  
> 
> Just think how cool it would be if we could attract lots of developers
> because they only have to get one little part of the plugins cvs and use a
> mainstraim gst release (source, debs or rpms) for the things they don't
> work on.
> 
> Right, so getting to the point : a good division IMO answers to two
> real-life needs :
> 
> a) people care about what dependencies a plugin has (ie what libs do
>    they need to install)
> b) people care about whether a plugin interfaces with the
>    outside world (does it read and write my format) or if it treats data
>    internally (I want cool effects !)
> 
> c) conveniently, most libraries only deal with either internal or external
>    data (or so I hope), so b) doesn't conflict with a)
> 
> So I propose a two-level structure :
> 
> 1) audio-ext audio-int
>    video-ext video-int
>    other-ext other-int
> 
>    these are six directories which are pretty unambiguous, as longs as
>    you allow for the fact that video can also contain audio stuff (because
>    no one watches video without audio), but only there where the
>    underlying library also treats them as one.  (If it bothers you that
>    it's called video then I have no problems with renaming it to something
>    like auvid or even audiovideo.)  So if it's pure audio, it goest into
>    audio-*, if it's also video it goes into video-*, and if it's anything
>    else it goes into other-*.  
> 
>    Other possible directories might be mixed-*, for things that
>    purposefully combine audio and video in an unstraightforward way
>    (like the synaesthesia plugin, for example).
>    If there is a need for it, then system might be a good dir as well,
>    though since it is mostly used for video anyway it might as well go
>    into video.
> 
> 2) in it's right first-level dir, I would put each plugin in a directory
>    based on the lib it depends on.
> 
> I think this is a manageable, straightforward an fairly unobtrusive
> layout.
> 
> Here's an idea of where some of the plugins would end up according to my
> view :
> 
> audio-ext/
> 	lame/
> 	mad/
> 	cdparanoia/
> 	wav/
> 	silence/
> 	vorbis/
> 	icecast/
> 	oss/
> 	esd/
> 	festival/
> 	arts/
> 
> audio-int/
> 	volume/
> 	audioscale/
> 	resample/
> 	stereo/
> 	adder/
> 
> video-ext/
> 	aa	
> 	xvideosink
> 	vgasink
> 	mpeg1video
> 	quicktime
> 	1394/
> 
> video-int/
> 	videoscale
> 	deinterlace
> 	colorspace
> 	median
> 
> other-ext/
> 	udp
> 	rtp
> 	gnome-vfs
> 
> 
> I hope this somewhat convinces you of my idea ;) I think it counters most
> of the arguments against my previous proposal, which were :
> a) categorization of plugins was ambiguous.  Now it's simple to decide
> where a plugin should go.
> b) There are too many levels.  Well, now there's only one more than the
> mess we're in currently.  (actually, if you think about it,
> gstreamer/plugins/mad is just as deep as plugins/audio-ext/mad, and
> gstreamer/plugins/filters/colorspace is even DEEPER than
> plugins/video-int/colorspace).
> 
> So, let's discuss this a bit and see if we can work something out, so that
> we can move forward quickly restructuring the whole thing before it spins
> out of control ;)
> 
> Thomas
> 
> The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
> <-*-                      -*->
> morgen wordt het beter beter voor iedereen
> dan krijg ik de strop
> en jij wat je verdiende
> <-*- thomas at apestaart.org -*->
> URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>