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

[Pierre Ynard]

> 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."