On 13/02/2016 11:22, Benoit Gschwind wrote:
>
> [snip]
>
Following a comment from Quentin Glidic on IRC, I read wrong the
snprintf (I readed printf ... a shame, my apology). Which make the patch
valid if output->base.name is not too long.

output->base.name is managed in the backend and is fixed-sized already.
The size I used is even way too large for the possible values here.

But I keep the following:


This case show that this approach is not very good, In that case the
developer must give a list of unbound outputs setup and key/value is not
well suited for that case. (there is some workaround, like using key
pattern).

This case also leave me to add that section/key/value is not a good
choice and you should stick to key/value.

I still prefer the opaque configuration structure with function to set
the structure content.

I am not sure how to understand that part (even with your precision on IRC) but I think it is relevant to remind something that I find really important (and not only for that specific comment):

We are designing the *backend* configuration API.
We agreed already that backends will be an internal implementation detail of libweston. As such, I (as a future libweston-based compositor writer) consider them as trusted, which means:
- They would not use getters to grab random parts of my configuration
- They should keep the options set “small” enough for end-users to write it in any text-based configuration format the compositor would like to use (Weston is currently using a KeyFile, which is a really common format and not really fitting for complex structures). I expect backends needing a really complex configuration to provide a GUI program, or use their own configuration file. DRM is probably the most complex backend we will have for quite a long time (I consider any future “hardware-based” backend will have similar needs), and it fits well in the INI/KeyFile format.


In the current form, my patch has one little (IMO) non-backward-compatible change: it does not use a duplicated name "[output]" for the section with the "name=" key as the selector. It is entirely doable if it is a requirement for this patch to be considered, but in this design, backends should use unique section names, since KeyFile parser (like GLib’s) can merge duplicate sections.


Cheers,

--

Quentin “Sardem FF7” Glidic
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to