[gst-devel] multifilesink and proposal to merge it with filesink

[Thomas Vander Stichele]

Hi,

> let me try to explain it a bit clearer. There's currently a bunch of
> plugins added to gst-plugins that *might* at *some point in time* be
> useful to other applications. However, currently, they're not. They're
> ususally being hacked up to only work with specific pipelines (simply
> because they don't do proper event handling, don't have proper state
> reset functions, etc.).

Looking at Zaheer's code and seeing him fix *other* elements' event code
so they do the right thing makes me believe he's making this element
work correctly and generically.  Of course, I didn't vet it completely,
but please do look at the code and element first before giving a blanket
reply.

>  The consequence of this is that these elements
> are maybe not *in theory*, but they are *in practice*
> application-specific. Other applications will not use them anytime soon.

Chicken-and-egg - applications won't ever use it if it's in some other
package on its own.  Applications will most certainly NOT require acast
as a dependency to get a plugin.

Maybe we should look at the list of applications using GStreamer
successfully currently and ask ourselves "how come we have such a small
list ?"

> * the plugin is now not expected to work in any application anymore, but
> only in that one single application. This prevents bug reports due to
> poor event handling, state reset handling and so on.

So write the application that also needs this.  FWIW, I've needed this
sort of functionality for a previous application (that I currently don't
maintain anymore) and it was exactly what I could have used.

Also, as Zaheer said, other people that were looking at GStreamer for a
possible solution to their problem have asked for such functionality. 
They probably decided not to use GStreamer in the end because the
functionality wasn't there.

Compare that to the number of elements we should be having this very
discussion about instead.  Don't throw out good new elements because
there are too many crap old ones.

> * the plugin interface (the way in which plugin and application
> interface; properties, interfaces, signals, etc.) is not public anymore,
> and is thus allowed to change at any point in time. The plugin interface
> of a plugin in gst-plugins may never regress during a stable series.

I agree with this - but it's not like there have been made exceptions or
people have plainly not cared in the past.

> This requires a *stable* and *well-thought-out* plugin interface. We
> doubt that all the recently added plugins are that far. This is not an
> offense to their developers, it's simply deduction: you ususally don't
> get it right the first time, and that's completely normal.

Agreed, but look at all the plugins that were already there - same
situation, with the added problem that they don't have a clear
maintainer anymore to fix their issues, or their maintainer lost
intrest.  So evaluate these new plugins on this problem in a few months'
time.

Also, the argument "you'll have to be stable until 0.9" doesn't really
mean much - most of the time it takes at least six months before people
realize what the correct end solution should be, and people seem to be
very willing and able to stick to a stable interface until the next
cycle of 6 months.

> * less plugin maintainance and less build time in gst-plugins.

The latter is probably the only reason we're even having this
discussion.  Which is a point I brought up more than a year ago, and it
didn't seem like people thought it was big enough of a problem last time
around.  So we didn't come to an agreement.  Which prompted me to wait
until other people also saw it as a problem, which seems to have
happened now.

I'm glad everyone realizes it really is an issue - but that doesn't mean
I'm just going to let people solve the actual problem the wrong way :)

> Now, I hope that's clear. What I'm saying is: keep it in your
> application, until other applications clearly see the need for this as
> well.

These applications have already seen the need.  Both applications
already written in the past, and applications still in the idea stage
from people that have given GStreamer a look to see if it fits their
need.

I'm very serious here - we are having the right discussion about
completely the wrong plugin.  Please start looking at all the others,
evaluate them with the same criteria, and only THEN come back to this
one.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Bye bye long day
need to sleep so much
ninety hours straight
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/