Plugins in separate module was ( [gst-devel] bindings)

[Bastien R. Nocera]

Christian Schaller wrote:

 > On 14 Aug 2001 23:11:11 +0100, Bastien Nocera wrote:
 >
 >> Would somebody care to move the lame plugin to a separate module ? With
 >>  the module separate, it would be easier for people to provide 
source/binary
 >>  packages of it that would be add-ons to the gstreamer  packages
 >> that will (soon ;) show up in the distributions.
 >>
 >> And I'm sure that lame packages would show up soon on FTP sites in 
patent-free countries.
 >>
 >>Or shall we start moving plugins in their own modules. I can think of a
 >>DVD playing module containing ac3dec, mpeg2dec, and dvdsrc plugins.
 >>
 >>Comments ?
 >>
 >
 > Actually I discussed this with Wim the other day on IRC altough with a
 > slightly different angle. My suggestion was aimed at solving the problem
 > of us depending on some extremely API unstable libraries.


Can you name them ? The most changing API I saw in GStreamer was its own ;)


 >
 > My suggestion for solving this is doing what Abiword does with some of
 > its dependencies like Expat or Wvware, namely add them to the source
 > distribution and install them into the abiword binary tree.
 >
 > So to take Bastiens DVD example, my idea would mean that we make a
 > separate DVD package and add the code of ac3dec unmodified to that.
 > When installed this package would install our version of ac3dec into
 > something like $prefix/share/gst/ac3dec


This would be a maintenance pita, but I reckon it would be possible. The
only problem is that you'd duplicate, and have huge tarballs for some
modules.

You're also not mentioning the LD_LIBRARY_PATH voodoo that the AbiWord
script is doing. Statically linking the library to the plugin would be
fine by me. The plugin would probably work across all the Linux
distributions of the same arch, for one version of Gstreamer, so adding
plugins would be a doodle.



 > That what other applications needing a older/newer version of ac3dec
 > than our plugin would cause depdency conflicts with GStreamer when
 > installed.
 >
 > Plugins which depends on more stable libraries (past 1.0), like our FLAC
 > or GNOME-VFS plugins we should not do this with.

The didn't address the lame plugin problem. Many distros/vendors will 
not ship the plugin for (idiotic) legal reasons


 >> >>patent-free countries.
 >>
 >> Or shall we start moving plugins in their own modules. I can think
 >>  of a  DVD playing module containing ac3dec, mpeg2dec, and dvdsrc
 >>  plugins.
 >>
 >> Comments ?
 >>
 >
 > Actually I discussed this with Wim the other day on IRC altough with
 >  a slightly different angle. My suggestion was aimed at solving the
 >  problem of us depending on some extremely API unstable libraries.


Can you name them ? The most changing API I saw in GStreamer was its own ;)


 >
 > My suggestion for solving this is doing what Abiword does with some
 > of its dependencies like Expat or Wvware, namely add them to the
 > source distribution and install them into the abiword binary tree.
 >
 > So to take Bastiens DVD example, my idea would mean that we make a 
separate
 >  DVD package and add the code of ac3dec unmodified to that. When
 > installed this package would install our version of ac3dec into something
 >  like $prefix/share/gst/ac3dec


This would be a maintenance pita, but I reckon it would be possible. The
only problem is that you'd duplicate, and have huge tarballs for some
modules.

You're also not mentioning the LD_LIBRARY_PATH voodoo that the AbiWord
script is doing. Statically linking the library to the plugin would be
fine by me. The plugin would probably work across all the Linux
distributions of the same arch, for one version of Gstreamer, so adding
plugins would be a doodle.



 > That what other applications needing a older/newer version of ac3dec than
 >  our plugin would cause depdency conflicts with GStreamer when installed.
 >

 >
 > Plugins which depends on more stable libraries (past 1.0), like our
 > FLAC or GNOME-VFS plugins we should not do this with.

The didn't address the lame plugin problem. Many distros/vendors will 
not ship the plugin for (idiotic) legal reasons. The ac3dec (see /.) and 
dvdsrc plugin (with decss compiled in) will probably have the same problems.

Cheers