Stephen,
I am fine with these issues. I have been told that the interfaces
are not nearly as "volatile" as it sounded in the proposal. I am
fine with the stated stability level in the document.
Thanks,
John
On 04/ 2/10 08:43 AM, Stefan Teleman wrote:
John Fischer wrote:
Stefan,
Thanks for being thorough as usual.
I have truncated the fast track below for the issues/concerns
that I would like to address in this email thread.
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 ].
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.
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.
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 ].
Are the file names and directory structure Uncommitted?
Or is this referring to the actual APIs? Or both?
Both.
2. Interface Evolution
What are the plans to mitigate against the "volatility" of
the community with regards to interface evolution? Will
multiple version be used or will we simply follow along?
I propose "follow along" here. Too often, maintaining multiple
versions creates a maintenance burden which is not justified by the
practical benefits.
Also, having multiple versions installed can easily create confusion.
Assuming that we have XCB Version x1.y1.z1 and XCB Version x2.y2.z2,
and we want to integrate a new, super-cool graphics library which uses
XCB, and can handle both versions of XCB above. Which version does it
pick ?
What are the plans when the "volatility" of the community
spills over? Will there be Release Notes issued? Other?
My assumption is that there will be a single version shipped.
There will be a single version shipped, and those cases where
incompatible changes are introduced by a new release, we warn the
interested parties [ i.e. Desktop / Userland ].
I am much less concerned with advertising XCB breakage in the upstream
communities. If XCB breaks API's for us, it also breaks API's for
everyone else. :-)
3. X11 Applications
All X11 Applications except those directly using Xtrans
will work with any instability within the underlying XCB
changes. Is that correct?
Only applications which were using Private Interfaces from Xtrans [
leading underscore for those interfaces ] will be affected.
I've been building the entire X Consolidation [ for my own personal
use ] since Xorg 1.5.3 with various versions of XCB, and there is only
one function in the SUN-DGA client library which requires a trivial
change because of the disappearance of an X11/Xtrans private function
[ _X11TransGetHostname, which fortunately has an identical replacement
X11 function named _X11GetHostname ].
--Stefan
--
Stefan Teleman
Oracle Corporation
[email protected]
_______________________________________________
opensolaris-arc mailing list
[email protected]
