Plan for libweston backend configuration?

[Bryce Harrington]

To followup Pekka's recent libweston thread, here's the next actions it
looks like we should take?

   a.  Revert 5ffbfffa
   b.  Land https://patchwork.freedesktop.org/patch/67547/, which covers
       the drm-backend.  (Is this patch proposal good as is, or would it
       benefit from any additional review?)
   c.  Defer the two alternative options for now
 	   https://patchwork.freedesktop.org/patch/73206/
       https://patchwork.freedesktop.org/patch/[73035,73036,73037,73038,73039]
   d.  Review/update wayland-backend and x11-backend to comply
   	   https://patchwork.freedesktop.org/patch/74553/
	   https://patchwork.freedesktop.org/patch/74504/

This establishes Giulio's "Well Defined Structs" approach for
configuring libweston backends.  This uses versioned structs for
communicating parameters with the backends.

If no one raises an objection to this plan, I can tackle (a), (b) and
(c) myself directly.  For (d), offhand it appears they at least need to
add the structure versioning support, but might be suitable to consider
landing after that?


---
A couple of more sophisticated solutions were proposed and evaluated,
but it feels like our requirements here are modest, and so simpler is
probably better.  Things aren't cast in stone here and we can always
move to something more advanced later if conditions warrant it.

In mind of this, here are the assumptions that are leading us to this
choice.  In the future if these assumptions fail to hold adequately,
then this design should be re-evaluated.

1.  libweston has no stability promises, and won't for a long time, and
    it is and will remain parallel installable.  We are freely able to
    redo tomorrow any bad decisions we make today.

2.  New options will be appended to the the struct, which will avoid ABI
    breaks.

3.  The struct is versioned, so if we do need to break ABI for some
    reason, we can and backends can thereby check and verify their
    version.

4.  Configuration needs by the backends are on the tame side, mostly
    just involving basic data types (strings, ints, etc.)

5.  Backend configuration is internal to the backend.  End users won't
    be exposed to it, and only backend developers will need to tinker
    with these things.

6.  Additions of or changes to configuration parameter definitions are
    going to be done by developers who are either part of the Wayland
    development community, or will be sending all of their changes to
    the community.  

7.  All libweston backends will be living in the weston repository.  We
    do not provide support for third-party backends.

It's probably non-fatal if we periodically violate one or two of these
assumptions, but if we get beyond that it should be a cue to revisit our
approach.


So far, two other alternatives were considered; here are the key design
differences:

A.  Opaque Structs
	https://patchwork.freedesktop.org/patch/73206/

	This still uses structs for sharing configuration parameters but the
	structs are hidden as internal details.  The backend instead uses
	function calls to fill in parameters.

	While this does decouple things a bit and avoid ABI breakge on
	structure definitions, this requires coding and maintaining an array
	of backend-specific functions, which bring their own API breakage
	potentials.

	This is essentially an incremental enhancement of the "Well Defined
	Structs" scheme, so would be straightforward to upgrade to later.


B.  Getter/Setters
	https://patchwork.freedesktop.org/patch/[73035,73036,73037,73038,73039]

	Establishes a key/value backend config API, with separate
	getter/setter calls for different config item data types.  Backends
	then call these getters to retrieve configuration variables.
	This system includes provision for sections and default values.

	This is certainly a much more flexible system, but many of the same
	problems will exist when configuration parameters change.  Just that
	instead of erroring at the API/ABI layer it breaks at the
	parser/configuration layer.  Shifting to this lower level means
	errors may get detected later on, or may be missed entirely, where a
	broken struct will be more highly visible.

Alternative A might be worth considering if we start seeing
proliferation of backend options, or if the configuration settings start
going beyond basic types.

Alternative B could become more convenient if we need to expose options
to end-users or if we start seeing third-party backends.

Bryce