[MPlayer-users] playlist file syntax

[James Gatt]

Quoting Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:

> Hi,
>
> First of all, sorry for confusing people,I didn't pay enough attention to the
> names :-(.
>
> > > > >Where comes the point to point out that you didn't answer the question
> > > > >what the feature you offer is. At least I didn't see it, only a
> proposal
> > > > >of a different playlist format.
> > > > >And by defending the current format is a way to make sure a new one
> isn't
> > > > >just a different piece of crap, but something really better. I guess
> we've
> > > > >had
> > > > >enough of that "let's replace that bug with another one" :-(.
> > > >
> > > > I do agree with not changing things for the sake of it, however I
> > > > haven't yet seen what I would call a good reason for keeping the
> > >
> > > Which was my point: You are asking for a good reason to keep the current
> > > format, whereas I (and probably some others) have not yet seen the reason
> for
> > > a new format. This seems the wrong order to me.
> >
> > Because the current format uses every available character other than
> linefeed as
> > a part of the filename, there is no room for any kind of extension. If
> every
> > suggestion will be refused if it breaks the current format then mplayer
> > playlists can never improve. I was questioning this reasoning, not
> suggesting a
> > new format. (The original suggestion was not mine.)
>
> It usually (always?) can be done without breaking old behaviour by adding
> options. I added OSD and aspect scaling to the gl vo, but you can still make
> it behave exactly as before...

I agree that is a good intent, but in the specific case of the playlist if every
character is reserved because it could form part of a filename then what changes
can be made?

> > > > >>I am having this rant because I've seen a lot of derogatory comments
> made
> > > > >>to
> > > > >>people asking innocent and often valid questions on this list. It is
> > > > >>foolish
> > > > >
> > > > >Some people might see it as derogatory that you decide what is
> innocent
> > > > >or valid...
> > > >
> > > > I don't see your point. I see comments that appear to me to be innocent
> > >
> > > that "appear to me" is what was missing in your first post IMHO.
> >
> > I think I am capable of having a reasonable opinion of what is innocent and
> / or
> > valid. People might not always agree with me, I don't expect them to. If I
>
> Well, my personal opinion is that opinions on such things can't be
> reasonable, but well ;-)
>
> > believe something is valid then I will say it is valid, just as I will say
> > grass is green, rather than grass appears to me to be green. Fortunately
> most
> > people don't take offense to this level of brevity; else the english
> language
> > would be even more verbose than it already is.
>
> Normally yes. But in some cases it is a good idea to add that verbosity.

Is that a fact, or your opinion? ;) It sounds like an opinion to me, but you
didn't state "in my opinion". Works both ways, but I wouldn't normally pick up
on it. Let's not discuss the use of the english language on the mplayer-users
list.

> > > > and valid, and people get flamed for writing them, like they are
> "lower"
> > > > beings than the "developers". That's out of order. I know it can get a
> > > > little bit frustrating when someone hasn't read and understood the
> right
> > > > section of the manual, but in that case the right thing to do is either
> > > > help them or shut up. I no way is it the right thing to be hostile, and
> > > > I've seen that on this list recently. I am not going to cite examples
> > > > because I don't want this to become personal.
> > >
> > > I can understand that, but I'm not sure if people would prefer being
> ignored
> > > - something I personally find worse...
> >
> > I guess not wanting to choose between being ignored or being flamed is one
> > reason I haven't posted any patches yet.
>
> I don't think a patch will get you treated any worse as these mails ;-)
> Especially as we are getting off-topic...

Agreed, although I particularly wouldn't like my work being dissed in the
presence of existing untidy code and whatever bug it was that I'd fixed.

> > > > >>for the core mplayer team to believe that everyone else is incapable
> of
> > > > >>coming
> > > > >>up with useful ideas and writing good code for them. If it is made
> too
> > > > >>hard for
> > > > >>people to submit patches that are accepted, then mplayer development
> will
> > > > >>simply
> > > > >>fork.
> > > > >
> > > > >I fail to see a fork as a threat.
> > > > >Anyway, quite a few people are active a few months
> > > > >and then aren't reachable by email forever, meaning that we are stuck
> with
> > > > >maintaining their patches. I have little motivation for applying a
> > > > >patch when I think that it will be a pain in the a** to maintain it,
> no
> > > > >matter how well it may work at the moment.
> > > >
> > > > If a fork occurred and several people decided they were interested in
> > > > improving the "other" version, then these people are a resource you
> have
> > > > lost access to. It won't make the original mplayer any worse, but it
> > > > won't help it improve either.
> > >
> > > Yes, but if they are good they will try other aproaches and make some
> things
> > > better (but I'm certain that there will be lots of things we will do
> > > better ;-) ). And if they aren't good it won't exist for long.
> >
> > If they are good then they will develop features or fix bugs that you would
> wish
> > you had the resources to have done. As the forked code progresses it
> becomes
> > harder to integrate changes from the "other" version.
>
> If they are that good that won't be neccessary for too long because then the
> "original" will probably disappear.

Wouldn't this depend on what the end users wanted. At the moment mplayer tries
to be all things to all people, whereas a forked version could specialise on
certain features or groups of end users at the expense of others, because these
certain features or users were not being well represented by the original
developers. In this scenario both versions would live and not share all of each
others good points.

> > > > A patch that will be difficult to maintain is not usually the best way
> > > > of solving the problem the patch was written for. However, quite a lot
> > > > of the mplayer code has clearly evolved much since it was originally
> > > > architected, and this alone can make for difficult maintenance.
> > >
> > > It does for sure! We are quite busy with fixing old bugs and bugs that
> show
> > > up because other bugs were fixed etc. That was one of the reasons why G2
> > > was started afaik. And it also is another reason for being reluctant to
> > > accept patches unless they are really convincing, we sure have more than
> > > enough bugs and ugly code.
> >
> > Sounds like you need some more maintainers to share the workload. I know
> too
> > many can lead to communication problems though. How many are there at the
> > moment?
>
> I agree we need more. See DOCS/tech/MAINTAINERS...

Will do.

Regards,
James.