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

[Thomas Vander Stichele]

Hi,

> So now the question is whether this is problematic. A few weeks ago,
> Benjamin sent an email to the list in which he raised the point of the
> overload of plugins being added to gst-plugins recently. He noted that
> most of those plugins had a pretty application-specific character, even
> though they might at some point in some way be useful to other plugins
> as well. I support the point he raised there and believe we should be
> more strict on what we add to gst-plugins. The reason for this is
> extremely simple: we do *not* have the manpower to maintain that,
> period. Benjamin raised more points, but this is the most important one
> for me.

So, there are various reasons for why we might want to split gst-plugins
or remove stuff from it:

A) it is a bitch to maintain
B) it takes too long to build
C) some plugins are not maintained correctly anymore, or have been
broken
D) some plugins have limited use
E) there are outside issues that suggest us splitting up

As a release manager, I felt A) the most over a year ago, which was why
I originally asked for a splitup.  Nobody seemed to think it was big
enough of an issue, so I let it rest until such a time that B) - E) have
become sufficiently annoying to people other than me.  That time has
finally come.

I completely support the idea of splitting up, going over plugins,
looking at what we should keep, removing some, and all that.  That's
fine, and we should do it.  Now that you all agree that it should be
done, I think we can finally actually do it :)

However.

What I absolutely DO NOT support is taking a plugin such as
multifilesink hostage until the splitup has been resolved.  It's
stupid.  If you were able to live with what I thought was a problem for
a year, than you can live with it until you have done what is the
correct solution.

There are plugins currently inside gst-plugins and even core that are
less valuable than multifilesink.  Ronald, you should realize that if a)
people on IRC have asked for something like this b) I've stated that
this is what I could have used in two projects I did c) it's useful in
acast d) Wim and Benjamin seemed to think it was useful enough to
actually comment on it and give hints on the desing and interface, then
there is a valid reason for it to be in gst-plugins.

I could easily give you a list of plugins for which this would be a lot
harder to support, that currently are in our CVS.

As an example, why do we have multifilesrc ? Is anyone ever using it ?
One possible use case would be "I have 2000 png's extracted out of a
movie and I want to play them as a movie."  Sounds fine, some projects
do something like this.  Do you need multifilesrc for this ? Yes.  So
what do you do if you have a movie and you want to write it to 2000
png's ? You need multifilesink.

It's that simple.  Either remove multifilesrc or add in multifilesink.
If you don't agree, provide arguments against this.

That's all I have to say about this particular plugin:
- don't hold it hostage, and with it the author who is a contributor. 
This is negative energy and stalls people from contributing because we
were too lazy, as a team, to fix the real issue.
- disprove its merit and prove the merit of other already included
plugins over this one

Now, let's please move on to resolving the actual problem at hand. 
Let's go over the plugins and make some decisions.  Let's decide what
criteria we want to use for deciding this, what to split out to.  Let's
not allow ourselves to be lazy with arguments like "but it's already
in".  It's the only way to fix the problem correctly.

Introducing a plugin stop is the wrong way.  It keeps good plugins out
and bad plugins in.  Thus, it actually decreases the overall quality
level of gst-plugins.

> In another reply in this same thread, Thomas raised the point that this
> plugin might very well be useful for some applications and that we
> should find another way of splitting up gst-plugins. If Thomas wants to
> continue that point, then I suggest he makes suggestions here in this
> thread, and that we *solve* the issue in this thread and find a
> solution.

I've made this point often enough before - now that you all agree it is
a problem, I'd like to hear YOUR thoughts on how to solve the split-up
issue.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
I won't leave you
all you have is that spell
cast it will you
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/