[vlc-devel] Factor HTTP/HTTPS/RTSP port in core

Pierre Ynard linkfanel at yahoo.fr
Fri Sep 16 21:12:32 CEST 2011

> That won't work for dual-stack.

Sure, the code needs to be adapted a bit to make it work.

> Even if we ignore this, it would be confusing in any case.

No, I disagree. I don't understand why you keep throwing around the word
"confusing" without facts.

> The current approach on the other hand, is quite clear, though
> different from earlier.

Don't be a GNOME simplicity nazi; of course it's clear, because it's
*dumbed down*

> And it still fails to address TLS certificate issues.

For the 4th time, what are the TLS issues? Anyway, the TLS and server
address issues are not really bound together.

> >    * decide whether we want unspecified/zero port values that can mean
> >      an OS-assigned port instead of being replaced by the default
> This is meant to be used for ephemeral ports, which those are not.
> I don't know any software that would allocate an ephemeral port by
> default, except where some kind of rendez-vous mechanism negotiates it
> (e.g. UPnP, FTP data, RTSP RTP/RTCP pair).

Okay, but I didn't mean it should be the default; just a feature
that could be used when you need it. A use-case mentioned earlier is
automated tests of server functionality.

> >    * choose between URI, the de facto standard "<host>:<port>"
> >      representation, separate host and port parameters, something
> >      else, or a combination thereof
> This is NOT a de facto standard for on the server/listening side. In
> fact, Apache separates the per host path "<Location /foo>" from the
> host name "<VirtualHost IP:port>".

So Apache uses the "host:port" representation too? Yes, that's exactly
my point. Right, that doesn't include the path, it would be separated in
another parameter.

> >  - convert to this consistent syntax all these parameters throughout
> >    the vlc code base, without breaking compatibility, adding new
> >    parameters where needed
> Consistent across access output destinations?

No, across the code base. Including access outputs yes, --sout which
also accepts an MRL in place of a sout block, the rtp sout and its sdp
parameter, VoD which still uses the path component of --rtsp-host,
the rc interface which expects <host>:<port>, telnet which accepts
<host>:<port> *and* a separate --telnet-port, the lua CLI which now
takes a telnet URL, DVB HTTP whose configuration is gone, and other
stuff given by grepping the help: --rmtosd-{host,port}, --sout-raop-host

> HTTP is now (mostly) consistent with file. FTP upload is kinda
> "special". UDP is legacy crap and is special too.

There are no central --file-host and --file-port options.

> Consistent server-side location and client-side HTTP URI make no
> sense. The first ones are not URIs and never were.

I'm not convinced that we can't use URIs to express server-side
locations. Anyway, we're discussing server side only.

> It is already mostly consistent across RTSP/HTTP(S) and has more or
> less always been.
> >  - if applicable, move configuration variables to a central location
> >    allowing to set defaults
> That is what this does...

No, this doesn't set defaults, implying they can be overriden. This sets
the one and unique value to be used everywhere.

Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

More information about the vlc-devel mailing list