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