[FFmpeg-devel] Ideas to replace the options system

[Michael Niedermayer]

On Fri, Dec 04, 2015 at 03:33:39PM +0100, Nicolas George wrote:
[...]
>   Extra features
> 
>     This system allows a few new interesting features. Some of them just
>     thanks to no longer worrying about sizeof(AVOption).
> 
>     Special syntaxes
> 
>       Any component can define its own syntax. It should not be abused,
>       since consistency is also good, but it will be useful sometimes.
> 
>     Polymorphism
> 
>       A field can accept different types, both at API level and for the
>       user. For example, a video size can be both a whole to accept size
>       names ("hd720") or individual numbers w and h.
> 
>     Namespaced sub-structures
> 
>       If the field "f" is itself a structure made of fields, including "a"
>       and "b", then several syntaxes can be allowed to set it:
>       "f.a=5:f.b=3", "f={a=5:b=3}", and optionally just "a=5:b=3" if there
>       are no field "a" and "b" in the parent structure.
> 
>     Hooks
> 
>       Fields can have a type that wraps their real type to perform extra
>       actions. For example set another field to indicate whether the option
>       was set by the user or left to default.
> 
>     Varying options
> 
>       New options can appear or disappear according to previously set
>       options, like the number of inputs for a filter. For example, a codec
>       context could accept "codec=libx264:crf=20" (but not
>       "crf=20:codec=libx264").
> 
>     Embedded documentation
> 
>       Types and fields can contain documentation, more than the simple
>       string currently in AVOption. An API should be available to build a
>       single documentation page for a given set of elements, pulling the
>       necessary dependencies (description for the syntax of fields) only
>       once, and at various detail levels: short summary for a tooltip or
>       full text with examples for the web page.
> 
>     Syntax validation and autocompletion 
> 
>       Parsers should have a dry-mode run where they read the string but do
>       not set values, to allow applications to check fields early. They
>       could even return suggested completions or corrections. (This is
>       somewhat incompatible with varying options, we can live with that.)
> 
> 
> Conclusion
> 
>   This has been a very lengthy exposition. Actually, I believe
>   implementation would not be that long. Well, longer than text, of course,
>   but not as gigantic as the explanation suggests. And a lot of steps can be
>   made incrementally.
> 
>   IMHO, the result would be both a better design and an enhanced user
>   experience.
> 
> 
> Personal note: if you skimmed through the whole thing and did not find it
> completely uninteresting, I would appreciate even short quick feedback,
> even "looks interesting, will read more carefully later".

the new features this would introduce sound interresting and also
reducing the escaping madness would be nice.
I wont comment on the implementation details as i have not thought
about them really but i definitly agree that there are limitations
in the current API and that improving it would be desirable.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151204/b7ae260e/attachment.sig>