[gst-devel] media-info, and old streaminfo tags

[Thomas Vander Stichele]

Hi,

> > Agreed.  OTOH, it was in the design and functionality in 0.6
> > 
> No it wasn't. It worked because no output sink cared about timestamp.

While that's fine for us, it's not really how application developers see
it.  I guess you'd have to be one to understand this argument.  I
understand though why you consider this to be an invalid argument as a
core hacker.

> > Now you lost me again - are you saying it is correct for apps to set the
> > output sink to NULL to pause it ?
> >  
> No, I'm saying they should set the output sink to NULL to release ressources 
> asociated with it.

I'm trying to believe here you're not running circles around the problem
on purpose :) I'll rephrase the question - what should applications, in
your opinion, do, given that they want to release the device, but
consequently the whole app blocks for $x seconds (where $x is the amount
of time it was playing before pressing pause) ? Ie, should applications
continue setting the sink to NULL, and the bug needing to be fixed is
clocking-related ? Or should applications be setting it to READY, and
should something else be fixed somewhere else ?

> > It's this second issue that is relatively new, I only know about it
> > since the last month.
> > 
> Same here. Which is why it isn't fixed.
> Sorry, but I can't fix everything right now.

Nobody is asking you to fix everything right now.  You were asking for
"why this bug is important all of a sudden", so I explained.

> You're twisting arguments.
> I never said we don't need users. I said users will live with it better than 
> when we break something by introducing buggy "release-device" properties. And 
> believe me, they will be buggy. Everything new and untested is buggy, 
> especially if it breaks the design.

OK.  I'll follow your lead, not add the release-device properties since
the code is untested, and I guess we'll just see.  It is entirely
possible that I am making this bigger than it is.  OTOH, no matter what
the reason, users (and I'm talking about "the people that will install
fc2 and press play in their music app) are not as forgiving as you
think.  But, I won't bring it up again.  If application developers using
GStreamer care, and realize these are issues, I hope they speak up, and
if not, we'll not worry about it.

> Yes, I respect that work.
> It's just funny that you show up 2 weeks before release starting to write code 
> insisting that this one stupid bug is so important that it must be fixed right 
> now.

Hm, I must have imagined adding i18n support or error handling then. 
The reason why I don't work more on the core is exactly because we lack
good design docs and I don't feel quite as comfortable going in there
and replacing bits based on an in-head design.  More on that further
down.

> Everything I do is documented. The files documenting how stuff works end in .c 
> and .h as is common everywhere in the Open Source world - I expect everyone 
> hacking on GStreamer and talking about design to be able to understand them 
> and to read them.

So you're saying we should keep it the way it is ? Well, I guess I
disagree.  There is nothing that says the current way state changes work
is better than the way it was before.  In fact, it is something that has
been changed more than once before.  It wouldn't surprise me if at some
point it got changed back again.

What I'm saying is, over a longer lifetime of the project, it makes
sense to write down design decisions in a better way than just source
code and comments.  Otherwise the intrinsic "design" of the code is only
the result of whoever was hacking on the core lately.

Or, otherwise said - just as you seem to disagree a lot with the design
Erik and Wim had on core issues, they might as well be disagreeing with
yours.  What happens if you lose interest, and someone else gains
interest ? Should he redo everything again to fit his idea of how it
would work ?

I'm not at all saying that your idea of the design is wrong; I'm saying
that, long-term, as a project, we'd benefit of having a clear set of
docs that detail the design.

While I fully realize that people might not have time for that or there
are other blocks to getting that done, that doesn't mean it shouldn't be
done or discussed on how we could make that happen.

Of course, if you feel we shouldn't even have this in an ideal
situation, then the discussion is moot.  It does block other people from
helping out though, with the usual results.  You would probably argue,
and not be wrong about it, that anyone is free to study the code enough
to participate in the design.  OTOH, you'd also say we only have 2
people doing that currently.

For the long-term viability of GStreamer, it might be a good idea to
find ways of expanding that number.

> You're autotooling doesn't do it in a different way.

The project is GStreamer, a streaming media framework.  autotools stuff
is infrastructure work, and sufficiently documented outside of
GStreamer.  Hardly something that needs a design within the context of
GStreamer :)

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
I'm so boring my clothes wanna keep
somebody else warm someone cooler
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/