Hi John,
My general answer is:
In my mind, Volatile is too harsh of a downgrade for XCB's interface
stability. Reasons are below.
The volatile change that has occurred recently in XCB was the
disappearance of one shared library object which was one of the main
interface providers for the X11 XCB bindings [ libxcb-xlib.so.0 ].
Meaning, the breakage occurred in one the most widely-used XCB shared
components.
The other XCB shared objects in XCB provide interfaces for their X11
Extensions counterparts -- as their physical names suggest -- Xv,
XvMC, Xfixes, etc.
It would seem reasonable that the XCB API's for these X Extensions
should provide the same stability classification as their X11
counterparts. Simply because it is not possible to break the XCB Xv
Extension's API in an incompatible way without breaking the X11 Xv
Extension's API in an incompatible way [ as an example ].
I read two main ideas here:
1. Difficulty in accepting that Uncommitted is not Committed (neither
at ARC, nor in real life :-).
2. Major software components developed in the open source community
keep giving us hints that there is a need for a new Stability
Classification -- perhaps named "External", which, in terms of
stability taxonomy, would rank below Uncommitted but above Volatile.
I don't know if this is feasible at this time.
To summarize: making everything in XCB Volatile seems overkill, at
least to me, and definitely inaccurate. Making everything in XCB
Uncommitted is closer to the truth, but comes with known caveats, and
with *potential*, but not professed, incompatible changes in the future.
Perhaps making libX11-xcb.so.1 Volatile, and maintaining everything
else as Uncommitted would more accurately reflect XCB's reality ?
--Stefan
------
John Fischer wrote:
Stefan,
I am good with most of the responses. I want to delve a little more into
the first issue.
1. Interfaces Uncommitted vs. Volatile
Why was Uncommitted chosen instead of Volatile? These
interfaces sure seem to lend themselves to Volatile with
stuff simply being removed at whim.
Because Volatile would mandate contracts. The likeliest consumers of
the XCB interfaces are Userland or Desktop applications [ GStreamer
would be a prime candidate ]. Even Gtk and/or Cairo might decide in
the near future to use XCB [ IIRC Cairo already looks for XCB if it is
available ].
Not necessarily. Volatile can depend upon Volatile without a contract.
In fact most of the Gnome stack is like that without contracts.
If GStreamer or Cairo would have to sign contracts with XCB for every
single micro release update, it would seriously hinder progress.
Especially in case these updates do not actually break anything.
That would be a compatible change and would not require a new contract.
Actually, a contract can span multiple micro releases. The contract is
simply
a formal mechanism describing the relationship between the 2 interested
parties when an interface is not stable enough to be consumed by one or
additional communication is desired. Thus a contract could be used for
a Committed interface. It would seem to me that since we know that the
interfaces for this project are "volatile" within the community that we
might
require contracts for things that are higher then Volatile to consume the
interfaces from this project.
Also, XCB consumers [ application or library developers ] seem to have
handled this implicit volatility quite well. They have accepted the
fact that XCB can change unexpectedly, and they check for the version
of XCB available at construction time, and adjust their software
accordingly.
So the open source community has accepted the "volatility" of these
interfaces. What about future customers that are not so tightly tied
into an open source community. How will they know that the interfaces
might change from micro release to micro release of XCB on Solaris?
Finally, the pitfalls with XCB's willingness to change only affect
direct consumers of XCB. Application which use X11 won't be affected
by these changes at all, since they will not see them [ in spite of
the fact that X11 binds to XCB ].
Again, I am fine with the X11 applications issue.
--
Stefan Teleman
Oracle USA Corporation
[email protected]
_______________________________________________
opensolaris-arc mailing list
[email protected]
