[vlc-devel] [PATCH 1/4] vlm: remove schedule media type

[Rémi Denis-Courmont]

Le perjantaina 28. elokuuta 2020, 22.50.40 EEST Jean-Baptiste Kempf a écrit :
> On Fri, 28 Aug 2020, at 09:55, Rémi Denis-Courmont wrote:
> > It's patently obvious that some people do need/want scheduled VLC usage.
> > But it's also obvious that they don't use VLM schedules for that.
> No,
> it is not obvious that they don't use VLM for that.

That is not what I wrote, neither what I meant, and that's not what this 
patchset is about.

Of course some people use VLM for scheduled pipelines. Nobody in their right 
mind would do or suggest to do that with actual VLM schedules objects though.

> I've seen numerous usages over the years of people using that.

> > They use custom wrappers and/or OS services (e.g. crond), via CLI, RC or
> > HTTP.And that's the right way to do it. Afterall,

> Not all of those exist on all the OS we support.

Which OS?

It is definitely possible on all supported desktop, server and embedded OSes. 
Desktop and server also pretty much all have scheduled tasks built-in. And we 
don't support VLM via app stores.

Really, no.

> > VLC can't persist and automatically start or restart itself anyway. It
> > can't even handle non-UTC civil time, nor weekdays. FFS, it doesn't even
> > warn about pending schedules when you try to quit it.

> All this is true.

> But I still object: removing this VLM feature opens the removal of all the
> depend code, notably scheduling for recordings.

You can still do that in many ways, and it hardly worked the way that's being 
removed.

> And then, when we need to add the feature back, it will be 20x time harder
> to put it back, because people will object about this.

> Bugs must be fixed,

And how do you fix them *here*?

Persistance cannot be added because it radically breaks backward compatibility 
with the current VLM configuration. This is a self-contradictory requirement.

Restarting is architecturally unfixable because it essentially needs a whole 
new executable (and OS-specific integration), and wouldn't be backward 
compatible either.

Daytime is impossible to fix on MacOS (according to comments by macOS devs), 
probably also on Windows.

So there you have it. There are only three options: remove it, keep it broken, 
or (expensively) replace it with something possibly not broken but 
incompatible...

> instead of removing features.

Reminds me, -S is still broken.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/