[vlc-devel] [PATCH] Add marq filter to libvlc

[Rémi Denis-Courmont]

On Tue, 07 Jul 2009 10:45:58 +0200, Olivier Aubert
<olivier.aubert at liris.cnrs.fr> wrote:
> On Mon, 2009-07-06 at 13:02 -0700, Pierre d'Herbemont wrote:
>> Functions are cheap, API safe, and doc friendly.
> Could be. It could also be argued that, given the dynamic nature of VLC,
> a stable API is desirable, but a means to take advantage of more
> advanced aspects of VLC is desirable too. So both approaches seem to me
> perfectly valid, although possibly conflicting.
> 
> Moreover, the cheapness of functions can be argued. Using functions
> means that compatibility is ensured at the compilation/linkage level.
> Using options (for which there should be some introspection facilities)
> means that compatibility can be dynamically achieved at runtime.

No it cannot. If we remove an option or change its semantics, it _will_
(more or less) silently break the caller. Realistically, we could check
that the option exists, has a matching type, and that the value is within
the range. That is about it.

However, are already do have the problems of leaking configuration values
through the API:
 - via libvlc_new(), and
 - via input item options.

> The proposed approach (dynamic update of config options) is perfectly
> stable as an API (it would be nice to have some introspection
> capabilities, though).

No. It is not stable. Sure the configuration functions can be stable, but
the semantics of the configured settings won't be. That is the whole point.

> Documentation exists (vlc --full-help --longhelp
> --help-verbose). What the approach uncovers is that option evolution
> should be treated with the same care as API evolution, with deprecated
> features, freezing phases, etc.

This is unrealistic. First we'd need to properly split the
variables/callbacks and configurations subsystem - which Gildas was
actually trying to merge but never fully did. Variables and callbacks can
fundamentally not be stable.

-- 
Rémi Denis-Courmont