[vlc-devel] [PATCH 1/2] cli: remove TCP mode (--rc-host)

[Pierre Ynard]

> The poll() code path exclude Windows.

No it doesn't?... Only when using a console, because using both a
console and sockets at the same time is unsupported on Windows.

> > If we do decide to deprecate TCP and recommend Unix sockets,
>
> We are not deciding that now. It was that way all along for the last
> 16 years or so. The only difference is that security is a much more
> pressing and visible issue nowadays.

Okay, let's assume that intent. The problem is still that, as I can't
see any material substantiation for it, users probably can't either.

> > Same, as I told you many times before, this is not a game of
> > tallying blame or invoking past mistakes to justify current ones.
>
> And the justification for having an ridiculous insecure TCP mode
> with broken (C) or no (Lua) support for event notifications is what
> exactly?

I don't motivate TCP mode from backwards compatibility, but as a good
and valuable feature with valid use cases that we want to provide,
and thus keep. I see no real justification for not having event
notifications in the lua CLI apart possibly from technical limitations
in lua bindings, so indeed this would have been another missing feature
never added there, you're right.

> As a matter of fact, most commands don't return anything at this
> time. I just added error codes, but that's brand new, and it's not
> propagated. And I can't propagate it in socket mode as that would
> obviously break backward compatibility.

> No! There is no such thing in 3.0 RC either, or any previous version.
> It was not even architecturally possible, as commands were (ab)using
> the variable callback system.

When I type commands, it outputs "returned 0 (no error)" and other
notification messages as a response, even over TCP, so I'm not sure
what you mean. Maybe you mean that it doesn't actually report errors,
but at least it shows that the command went through, and the error part
sounds like it wouldn't be much more difficult to fix now thanks to your
efforts.

> And really, that's the whole point: the only motivation for TCP
> mode would be backward compatibility. But if we can't keep backward
> compatibility because we want to add a password test, a prompt and/or
> a result code, then that's moot.

I disagree that backward compatibility is the whole point. Also,
requiring to set a new setting for the password is a whole lot less
problematic than requiring to arrange a new channel or switch to a new
remote interface.

And the switch away from the lua CLI involves many small differences in
features and output; adding a prompt (which I'm not saying I advocate)
would actually maintain compatibility from 3.0, except on Windows where
the lua CLI wasn't the default. I don't think you'd consider those minor
things as problematic for the transition.

> > I did already have a word with him about it, he confirmed what's
> > written in the notes.
>
> That's not my problem.

What if I said that back to you, that what you bring up is not my
problem? This is a team project.

> Regressions were fixed, except for --cli-host which you just rejected,
> so that's on you.

First, thanks for revisiting pending issues with the CLI. I'm all for
taking the transition out of half-broken limbo and finishing it, but
what I worry more about is things like cli.lua and telnet still being
around, than obsoleting --cli-host. It's not that I rejected your patch
so much that it doesn't apply on its own. If you want to push that line
for now until we consider actually porting --cli-host, fine with me.

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