From alan.coopersmith@oracle.com Thu Apr 1 15:51:17 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o31MpGgD006801 for ; Thu, 1 Apr 2010 15:51:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o31MpGwZ019799 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 1 Apr 2010 15:51:16 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L070070DZHGBV00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Apr 2010 16:51:16 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L070072PZHF2QB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Apr 2010 16:51:15 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o31MpFNe021853 for ; Thu, 01 Apr 2010 22:51:15 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o31MpBbG013003; Thu, 01 Apr 2010 22:51:12 +0000 (GMT) Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 139955331270162221; Thu, 01 Apr 2010 15:50:21 -0700 Received: from [129.145.155.53] (/129.145.155.53) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Apr 2010 15:50:20 -0700 Date: Thu, 01 Apr 2010 15:50:19 -0700 From: Alan Coopersmith Subject: XCB (X Protocol C-Language Bindings) [PSARC/2010/109 FastTrack timeout 04/08/2010] To: PSARC-ext Cc: Stefan Teleman Message-id: <4BB5232B.5070508@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_btaErpGTLCR0j5pkYSsovw)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BB52360.00CA:SCFMA4539814,ss=1,fgs=0 User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 26323 This is a multi-part message in MIME format. --Boundary_(ID_btaErpGTLCR0j5pkYSsovw) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT I am sponsoring the following fasttrack for Stefan Teleman. The timeout is set for next Thursday, April 8. Additional materials are attached to this e-mail and available in the case directory. The case requests a patch release binding, and describes how it might be implemented in Solaris 10, but no commitment is made to a Solaris 10 delivery, nor is a Solaris 10 delivery plan in place at this time. -Alan Coopersmith- alan.coopersmith@oracle.com Oracle Solaris Platform Engineering: X Window System Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: XCB [ The X Protocol C-Language Bindings ] 1.2. Name of Document Author/Supplier: Author: Stefan Teleman 1.3 Date of This Document: 01 April, 2010 4. Technical Description Introducing XCB [ The X Protocol C-Language Bindings ] with X11 in Solaris Stefan Teleman 29 March 2010 1. Summary and motivation XCB [ The X Protocol C-Language Bindings ] is intended as an API and ABI incompatible replacement for Xlib. It is neither designed, nor intended as a compatible plug for Xlib. Further details about the XCB ABI and its intended [ and unintended ] consequences on libX11 are discussed below. XCB provides several advantages over the existing Xlib implementation: [a] small footprint [b] protocol direct access [c] latency hiding [d] improved thread support [e] extensibility XCB is delivered as a self-contained collection of shared library objects, header files, XML schema definition files, Python precompiled object files, and pkg-config component discovery files. A full and complete installation of XCB must be constructed from three different components: - xcb-proto - libxcb - xcb-util Constructing XCB is dependent on libXau, libXdmcp and libXtrans. The existing libX11.so.4 [ currently libX11 Version 1.3.2 ] provides an optional software construction dependency on XCB: the libX11 library can be XCB-enabled at software construction time [ ./configure ]. Enabling XCB in Xlib is an ABI compatible change: it alters neither the programmatic facilities, nor the public interfaces exposed by libX11. Further details of XCB's design, and the implications resulting from enabling XCB in libX11 are discussed below. This Case proposes the integration of the latest version of XCB compatible with libX11: - xcb-proto version 1.5 - libxcb version 1.4 - xcb-util version 0.3.6 For the purposes of this Document, ${PYTHON_VERSION} refers to Python 2.6. [6] This Case seeks Micro/Patch release binding. 2. Technical issues 2.1. Key Objects 2.1.1. Shared Libraries: /usr/lib/libX11-xcb.so.1 /usr/lib/libxcb.so.1 /usr/lib/libxcb-composite.so.0 /usr/lib/libxcb-damage.so.0 /usr/lib/libxcb-dpms.so.0 /usr/lib/libxcb-dri2.so.0 /usr/lib/libxcb-glx.so.0 /usr/lib/libxcb-randr.so.0 /usr/lib/libxcb-record.so.0 /usr/lib/libxcb-render.so.0 /usr/lib/libxcb-res.so.0 /usr/lib/libxcb-screensaver.so.0 /usr/lib/libxcb-shape.so.0 /usr/lib/libxcb-shm.so.0 /usr/lib/libxcb-sync.so.0 /usr/lib/libxcb-xevie.so.0 /usr/lib/libxcb-xf86dri.so.0 /usr/lib/libxcb-xfixes.so.0 /usr/lib/libxcb-xinerama.so.0 /usr/lib/libxcb-xinput.so.0 /usr/lib/libxcb-xtest.so.0 /usr/lib/libxcb-xv.so.0 /usr/lib/libxcb-xvmc.so.0 /usr/lib/libxcb-atom.so.1 /usr/lib/libxcb-aux.so.0 /usr/lib/libxcb-event.so.1 /usr/lib/libxcb-icccm.so.1 /usr/lib/libxcb-image.so.0 /usr/lib/libxcb-keysyms.so.1 /usr/lib/libxcb-property.so.1 /usr/lib/libxcb-render-util.so.0 /usr/lib/libxcb-reply.so.1 [ plus the corresponding 64-bit objects ] 2.1.2. Header files: /usr/include/xcb/xcb.h /usr/include/xcb/*.h [ exclusive of xcb.h ] 2.1.3. Metaprogramming XML Objects: /usr/share/xcb/*.xml 2.1.4. Component Discovery [ pkg-config ] Objects: /usr/lib/pkgconfig/xcb.pc /usr/lib/pkgconfig/xcb-*.pc [ plus the corresponding 64-bit pkg-config objects ] 2.1.5. [ xcbgen ] Python utility components: /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/*.py There are no 64-bit Python objects for [ xcbgen ]. A complete listing of all the XCB shared libraries, header files, metaprograming XML files, pkg-config component discovery files, and [ xcbgen ] Python utility files is available in Appendix 1 of the ARC Case Materials. 2.2. XCB Construction, [ xcbgen ] and XCB Extensibility XCB's shared library objects provide interface wrappers around existing X11 Extensions [ and their corresponding shared libraries ]. This implementation encapsulation mechanism is consistent with one of XCB's stated primary goals: direct protocol access. XCB's software construction mechanism is based on meta-programming. The XML metaprogramming objects enumerated in [ 2.1.3 ] are used to generate translation units and associated header files for XCB's shared library objects via [ xcbgen ]. [ xcbgen ] is a Python utility delivered by the xcbproto component. XCB follows the standardized X component delivery design, by providing an xcbproto component and a separate, but xcbproto dependent XCB Component Collection. [ xcbgen ] enforces a relatively liberal dependency constraint on Python: it requires Python >= 2.5. Python objects are delivered by XCB in the standard Solaris Python package collection location: ${PREFIX}/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/ The [ xcbgen ] Python utiliy is of interest to XCB's construction mechanism, and to XCB developers writing new XCB extensions. It is not used outside of these two cases. The XCB XML Interface Definition Objects expose elements which define the interfaces, interface dependencies and formal relations between interface definitions for the XCB functions implemented in each translation unit. It is implied, and expected, that the XCB protocol meta-descriptions are formally verified against the existing, published specifications for the X protocol and protocol extensions they intend to replace. This reliance on meta-programmed interface definitions provides developers with an implicitly formalized [ and relatively easy ] mechanism for extending XCB: new XCB interfaces can be generated simply by creating XML Metadata Interface Definition Objects, and by generating their corresponding translation unit[s] and the resulting Shared Library. 2.3. Programmatic Facilities An example of constructing an XCB application is provided in [2]. If an application relies exclusively on Xlib's Committed Interfaces, XCB introduces no ABI or API incompatible changes. Applications will continue to work as expected, unchanged. Applications can import from, and bind to, XCB's Interfaces directly, bypassing Xlib and all the other X Extensions Libraries [ examples: GStreamer and libxine ]. This creates a direct depenedency on XCB's Interfaces. 2.4. Interface Stability The Shared Library Objects delivered by XCB do not contract, or imply, at this time, an interface stability commitment. Furthermore, there appears to be little guarantee that the physical presence of the XCB objects will be maintained across XCB releases. For example, libxcb-xlib.so.0 and its corresponding xcb-xlib.pc pkg-config file have been physically removed in a previous release version of XCB [ 1.1.92 ]. It is unspecified, at this time, if XCB will maintain its current physical object structure, or will undergo incompatible changes in the future. In spite of this apparent volatility, consumers of XCB should be allowed to test for XCB's physical object structure, and for explicit vesions of XCB, via standard pkg-config mechanisms. These consumers may also choose to bind directly to XCB's public interfaces. The potential instability of XCB's Interfaces creates a direct explicit binding between a given XCB release and its interface consumers. Applications binding directly to XCB's Interfaces must recognize, and adjust to, the potentially incompatible ABI and API changes which may occur in future releases of XCB. The responsibility for resolving any API or ABI incompatibilities between different release versions of XCB is explicitly delegated to the application consuming XCB's Interfaces. Existing pkg-config mechanisms are necessary and sufficient for discovering and enforcing XCB's interfaces particulars. 2.5. API, ABI and Programming Considerations The canonical Xlib Interfaces rely on the availability of a well-known, standard libX11 data structure: the [ X11 ] Display. Passing a Display pointer as an argument to a libX11 function is a well-known libX11 programming and interface design idiom. XCB introduces a different and incompatible data structure, similar in use to the X11 Display: the xcb_connection_t. There exists a striking similarity between the libX11 interface design idiom described above, and the XCB interface design idiom: many XCB functions take an xcb_connection_t pointer as an argument, akin to the Display pointer argument in libX11. XCB does not require the use, or availability, of a X11 Display structure in its API. Also, XCB does not provide a mechanism for obtaining a Display structure pointer from an existing, and valid, xcb_connection_t. It is entirely possible to construct an XCB application without using a libX11 Display structure. In fact, the concept of a libX11 Display is entirely absent from XCB's design: XCB provides a connection to a X server [ xcb_connection_t ], and [ optionally ] a XCB Screen [ identified by an integer screen enumerator ]. Enabling XCB in Xlib creates the possibility of mixing Xlib and XCB calls [ with documented restrictions ]. This feature enables a gradual application migration from Xlib to XCB [ and is currently required for applications using the GLX Extension ]. However, only one of either Xlib or XCB can manage the event queue at any discrete point in time. Programmatic facilities for switching the event queue handlers between Xlib and XCB exist. These facilities, and their restrictions are documented in the XCB API Manual. [1] XCB has been tested and verified to work on recent builds of Nevada, and on recent Update Releases of Solaris 10, going back to Solaris 10 Update 4. Interface Stability warnings outlined in 2.4 apply. XCB exports C and [ identical ] C++ Interfaces. 2.6. Known Limitations and Enhancements The current implementation of XCB does not provide full feature parity with the existing GLX Extension implementation. Usage of the GLX Extension with XCB still requires the usage of an X11 Display pointer. A future ARC Case will discuss a full XCB-based implementation of the GLX Extension. A different, future ARC Case will discuss a full XCB-based implementation of the Trusted Solaris Extensions for X [ XTSol ]. It is of interest to note that canonical XCB releases provide a XCB implementation of SELinux [ libxcb-selinux.so.0 ]. The XSUNSHMEM and SUN-DGA Extensions will not be re-implemented in XCB. 2.7. Documentation XCB is documented in HTML format at [1]. This integration will deliver the complete XCB HTML Manual, as provided in [1]. 3. Interfaces 3.1. Interface Stability This Case proposes the following Interface Stability Classification for XCB's components: Component Name Interface Stability -------------- ------------------- libX11-xcb.so.1 Uncommitted libxcb.so.1 Uncommitted libxcb-composite.so.0 Uncommitted libxcb-damage.so.0 Uncommitted libxcb-dpms.so.0 Uncommitted libxcb-dri2.so.0 Uncommitted libxcb-glx.so.0 Uncommitted libxcb-randr.so.0 Uncommitted libxcb-record.so.0 Uncommitted libxcb-render.so.0 Uncommitted libxcb-res.so.0 Uncommitted libxcb-screensaver.so.0 Uncommitted libxcb-shape.so.0 Uncommitted libxcb-shm.so.0 Uncommitted libxcb-sync.so.0 Uncommitted libxcb-xevie.so.0 Uncommitted libxcb-xf86dri.so.0 Uncommitted libxcb-xfixes.so.0 Uncommitted libxcb-xinerama.so.0 Uncommitted libxcb-xinput.so.0 Uncommitted libxcb-xlib.so.0 Uncommitted libxcb-xtest.so.0 Uncommitted libxcb-xv.so.0 Uncommitted libxcb-xvmc.so.0 Uncommitted libxcb-atom.so.1 Uncommitted libxcb-aux.so.0 Uncommitted libxcb-event.so.1 Uncommitted libxcb-icccm.so.1 Uncommitted libxcb-image.so.0 Uncommitted libxcb-keysyms.so.1 Uncommitted libxcb-property.so.1 Uncommitted libxcb-render-util.so.0 Uncommitted libxcb-reply.so.1 Uncommitted 3.2. Interface Dependencies and Compatibility XCB's Interface Table is provided in the ARC Case Materials directory [ xcb-interface-table.txt ]. Introducing XCB creates no additional run-time dependencies beyond those already present in the X Consolidation. libX11 with XCB imports interfaces from: - libxcb.so.1 libxcb.so.1 imports interfaces from: - libXau.so.6 - libXdmcp.so.6 Existing applications binding to Xlib's Committed Public Interfaces [ libX11 ] are unaffected by the private implementations changes created by XCB, and will continue to work as expected. Applications consuming Xlib Project Private interfaces may break. XCB removes a number of Xlib Project Private Interfaces from libX11 [ specifically from Xtrans ]. Details are provided in the Interface Table. XCB creates a compile-time dependency on Python 2.6 [ SUNWPython26 ]. 4. Packaging This Case proposes the following packaging structure for XCB: 4.1. IPS Packaging: - The libraries, headers, and pkg-config discovery files for the main xcb libraries, and the xcbgen developer tool will all be delivered in pkg:x11/library/libxcb. - The libraries, headers, and pkg-config discovery files for the additional libraries from the xcb-util collection will be delivered in pkg:x11/library/xcb-util. In both packages, the headers, pkg-config files & xcbgen files will all be part of the developer facet to avoid installation when minimizing for non-development systems. 4.2. SVR4 Packaging [ Solaris 10 ]: - XCB shared library objects, and pkg-config discovery files will be delivered in the existing SUNWxwplt package. This is required because of libX11's acquired explicit dependency on XCB, and avoids creating a new package dependency for SUNWxwplt. - XCB header files will be deliverd in the existing SUNWxwinc package. This will maintain consistency with the existing SUNWxwplt package object delivery design. - [ xcbgen ] objects will be delivered in a new package named SUNWxcbgen. As explained above, [ xcbgen ] is not a run-time dependency of XCB, and is of interest only to XCB developers. Application developers relying on XCB's canonical Public Interfaces, and who do not intend to extend the XCB API, do not need access to xcbgen, and may choose to omit its installation alltogether. 5. References [0] http://www.x.org/ [1] http://xcb.freedesktop.org/manual/index.html [2] http://en.wikibooks.org/wiki/X_Window_Programming/XCB [3] http://www.linuxshowcase.org/2001/full_papers/massey/massey.pdf [4] http://www.usenix.org/events/usenix02/tech/freenix/full_papers/sharp/sharp_html/index.html [5] http://www.usenix.org/events/usenix02/tech/freenix/full_papers/massey/massey_html/index.html [6] PSARC/2009/043 [ Python 2.6 ] 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open --Boundary_(ID_btaErpGTLCR0j5pkYSsovw) Content-type: text/plain; name=xcb-interface-table-07.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=xcb-interface-table-07.txt Introducing XCB [ The X Protocol C-Language Bindings ] with X11 in Solaris Stefan Teleman 29 March 2010 ======================== Interface Table for XCB ======================== 1. Exported Interfaces Interface Interface Comments Classification =============================================================== libX11-xcb.so.1 Uncommitted libxcb.so.1 Uncommitted libxcb-composite.so.0 Uncommitted libxcb-damage.so.0 Uncommitted libxcb-dpms.so.0 Uncommitted libxcb-dri2.so.0 Uncommitted libxcb-glx.so.0 Uncommitted libxcb-randr.so.0 Uncommitted libxcb-record.so.0 Uncommitted libxcb-render.so.0 Uncommitted libxcb-res.so.0 Uncommitted libxcb-screensaver.so.0 Uncommitted libxcb-shape.so.0 Uncommitted libxcb-shm.so.0 Uncommitted libxcb-sync.so.0 Uncommitted libxcb-xevie.so.0 Uncommitted libxcb-xf86dri.so.0 Uncommitted libxcb-xfixes.so.0 Uncommitted libxcb-xinerama.so.0 Uncommitted libxcb-xinput.so.0 Uncommitted libxcb-xtest.so.0 Uncommitted libxcb-xv.so.0 Uncommitted libxcb-xvmc.so.0 Uncommitted libxcb-atom.so.1 Uncommitted libxcb-aux.so.0 Uncommitted libxcb-event.so.1 Uncommitted libxcb-icccm.so.1 Uncommitted libxcb-image.so.0 Uncommitted libxcb-keysyms.so.1 Uncommitted libxcb-property.so.1 Uncommitted libxcb-render-util.so.0 Uncommitted libxcb-reply.so.1 Uncommitted xcbgen Uncommitted bigreq.xml Project Private composite.xml Project Private damage.xml Project Private dpms.xml Project Private dri2.xml Project Private glx.xml Project Private randr.xml Project Private record.xml Project Private render.xml Project Private res.xml Project Private screensaver.xml Project Private shape.xml Project Private shm.xml Project Private sync.xml Project Private xc_misc.xml Project Private xevie.xml Project Private xf86dri.xml Project Private xfixes.xml Project Private xinerama.xml Project Private xinput.xml Project Private xproto.xml Project Private xselinux.xml Project Private xtest.xml Project Private xv.xml Project Private xvmc.xml Project Private 2. Imported Interfaces Interface Interface Comments Classification ================================================================== libX11.so.4 Committed libXau.so.6 Committed libXdmcp.so.6 Committed Python 2.6 Uncommitted 3. Project Private Interfaces removed from libX11 [ XTrans ] XESetCopyEventCookie XESetWireToEventCookie _X11TransBytesReadable _X11TransClose _X11TransCloseForCloning _X11TransConnect _X11TransConnectDisplay _X11TransConvertAddress _X11TransDisconnect _X11TransFreeConnInfo _X11TransGetConnectionNumber _X11TransGetHostname _X11TransGetMyAddr _X11TransGetPeerAddr _X11TransIsLocal _X11TransOpenCLTSClient _X11TransOpenCOTSClient _X11TransRead _X11TransReadv _X11TransSetOption _X11TransWrite _X11TransWritev _XConnectDisplay _XDisconnectDisplay _XSendClientPrefix 4. Packaging Interface Interface Comments Classification =============================================================== SUNWxwplt Committed Modified SUNWxwinc Committed Modified SUNWxcbgen Uncommitted New pkg:x11/library/libxcb Uncommitted New pkg:x11/library/xcb-util Uncommitted New 5. References PSARC/2003/210 X11 Library Cleanup [ libXau.so.6, libXdmcp.so.6 ] PSARC/2009/043 Python 2.6 and 3.0 LSARC/2009/666 Update libX11 to 1.3 [ libX11.so.4 ] --Boundary_(ID_btaErpGTLCR0j5pkYSsovw) Content-type: text/plain; name=xcb-appendix-1-07.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=xcb-appendix-1-07.txt Introducing XCB [ The X Protocol C-Language Bindings ] with X11 in Solaris Stefan Teleman 29 March 2010 APPENDIX 1: Objects Delivered By XCB 1. Header Files: 1.1. libxcb: /usr/include/xcb/bigreq.h /usr/include/xcb/composite.h /usr/include/xcb/damage.h /usr/include/xcb/dpms.h /usr/include/xcb/dri2.h /usr/include/xcb/glx.h /usr/include/xcb/randr.h /usr/include/xcb/record.h /usr/include/xcb/render.h /usr/include/xcb/res.h /usr/include/xcb/screensaver.h /usr/include/xcb/shape.h /usr/include/xcb/shm.h /usr/include/xcb/sync.h /usr/include/xcb/xc_misc.h /usr/include/xcb/xcb.h /usr/include/xcb/xcbext.h /usr/include/xcb/xevie.h /usr/include/xcb/xf86dri.h /usr/include/xcb/xfixes.h /usr/include/xcb/xinerama.h /usr/include/xcb/xinput.h /usr/include/xcb/xproto.h /usr/include/xcb/xselinux.h /usr/include/xcb/xtest.h /usr/include/xcb/xv.h /usr/include/xcb/xvmc.h 1.2. xcb-util: /usr/include/xcb/xcb_atom.h /usr/include/xcb/xcb_aux.h /usr/include/xcb/xcb_bitops.h /usr/include/xcb/xcb_event.h /usr/include/xcb/xcb_icccm.h /usr/include/xcb/xcb_image.h /usr/include/xcb/xcb_keysyms.h /usr/include/xcb/xcb_pixel.h /usr/include/xcb/xcb_property.h /usr/include/xcb/xcb_renderutil.h /usr/include/xcb/xcb_reply.h 2. Component Discovery [ pkg-config ] Files: 2.1. xcbproto: /usr/share/pkgconfig/xcb-proto.pc 2.2. libxcb: /usr/lib/pkgconfig/x11-xcb.pc /usr/lib/pkgconfig/xcb-composite.pc /usr/lib/pkgconfig/xcb-damage.pc /usr/lib/pkgconfig/xcb-dpms.pc /usr/lib/pkgconfig/xcb-dri2.pc /usr/lib/pkgconfig/xcb-glx.pc /usr/lib/pkgconfig/xcb-randr.pc /usr/lib/pkgconfig/xcb-record.pc /usr/lib/pkgconfig/xcb-render.pc /usr/lib/pkgconfig/xcb-res.pc /usr/lib/pkgconfig/xcb-screensaver.pc /usr/lib/pkgconfig/xcb-shape.pc /usr/lib/pkgconfig/xcb-shm.pc /usr/lib/pkgconfig/xcb-sync.pc /usr/lib/pkgconfig/xcb-xevie.pc /usr/lib/pkgconfig/xcb-xf86dri.pc /usr/lib/pkgconfig/xcb-xfixes.pc /usr/lib/pkgconfig/xcb-xinerama.pc /usr/lib/pkgconfig/xcb-xinput.pc /usr/lib/pkgconfig/xcb-xtest.pc /usr/lib/pkgconfig/xcb-xv.pc /usr/lib/pkgconfig/xcb-xvmc.pc /usr/lib/pkgconfig/xcb.pc /usr/lib/${MACH64}/pkgconfig/x11-xcb.pc /usr/lib/${MACH64}/pkgconfig/xcb-composite.pc /usr/lib/${MACH64}/pkgconfig/xcb-damage.pc /usr/lib/${MACH64}/pkgconfig/xcb-dpms.pc /usr/lib/${MACH64}/pkgconfig/xcb-dri2.pc /usr/lib/${MACH64}/pkgconfig/xcb-glx.pc /usr/lib/${MACH64}/pkgconfig/xcb-randr.pc /usr/lib/${MACH64}/pkgconfig/xcb-record.pc /usr/lib/${MACH64}/pkgconfig/xcb-render.pc /usr/lib/${MACH64}/pkgconfig/xcb-res.pc /usr/lib/${MACH64}/pkgconfig/xcb-screensaver.pc /usr/lib/${MACH64}/pkgconfig/xcb-shape.pc /usr/lib/${MACH64}/pkgconfig/xcb-shm.pc /usr/lib/${MACH64}/pkgconfig/xcb-sync.pc /usr/lib/${MACH64}/pkgconfig/xcb-xevie.pc /usr/lib/${MACH64}/pkgconfig/xcb-xf86dri.pc /usr/lib/${MACH64}/pkgconfig/xcb-xfixes.pc /usr/lib/${MACH64}/pkgconfig/xcb-xinerama.pc /usr/lib/${MACH64}/pkgconfig/xcb-xinput.pc /usr/lib/${MACH64}/pkgconfig/xcb-xtest.pc /usr/lib/${MACH64}/pkgconfig/xcb-xv.pc /usr/lib/${MACH64}/pkgconfig/xcb-xvmc.pc /usr/lib/${MACH64}/pkgconfig/xcb.pc 2.2. xcb-util: /usr/lib/pkgconfig/xcb-atom.pc /usr/lib/pkgconfig/xcb-aux.pc /usr/lib/pkgconfig/xcb-event.pc /usr/lib/pkgconfig/xcb-icccm.pc /usr/lib/pkgconfig/xcb-image.pc /usr/lib/pkgconfig/xcb-keysyms.pc /usr/lib/pkgconfig/xcb-property.pc /usr/lib/pkgconfig/xcb-renderutil.pc /usr/lib/pkgconfig/xcb-reply.pc /usr/lib/${MACH64}/pkgconfig/xcb-atom.pc /usr/lib/${MACH64}/pkgconfig/xcb-aux.pc /usr/lib/${MACH64}/pkgconfig/xcb-event.pc /usr/lib/${MACH64}/pkgconfig/xcb-icccm.pc /usr/lib/${MACH64}/pkgconfig/xcb-image.pc /usr/lib/${MACH64}/pkgconfig/xcb-keysyms.pc /usr/lib/${MACH64}/pkgconfig/xcb-property.pc /usr/lib/${MACH64}/pkgconfig/xcb-renderutil.pc /usr/lib/${MACH64}/pkgconfig/xcb-reply.pc 3. XML Metadata Interface Definition Objects: 3.1. xcbproto: /usr/share/xcb/xcb.xsd /usr/share/xcb/bigreq.xml /usr/share/xcb/composite.xml /usr/share/xcb/damage.xml /usr/share/xcb/dpms.xml /usr/share/xcb/dri2.xml /usr/share/xcb/glx.xml /usr/share/xcb/randr.xml /usr/share/xcb/record.xml /usr/share/xcb/render.xml /usr/share/xcb/res.xml /usr/share/xcb/screensaver.xml /usr/share/xcb/shape.xml /usr/share/xcb/shm.xml /usr/share/xcb/sync.xml /usr/share/xcb/xc_misc.xml /usr/share/xcb/xevie.xml /usr/share/xcb/xf86dri.xml /usr/share/xcb/xfixes.xml /usr/share/xcb/xinerama.xml /usr/share/xcb/xinput.xml /usr/share/xcb/xproto.xml /usr/share/xcb/xselinux.xml /usr/share/xcb/xtest.xml /usr/share/xcb/xv.xml /usr/share/xcb/xvmc.xml 4. [ xcbgen ] Python Utility Objects: 4.1. xcbproto: /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/__init__.py /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/__init__.pyc /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/__init__.pyo /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/error.py /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/error.pyc /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/error.pyo /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/expr.py /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/expr.pyc /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/expr.pyo /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/matcher.py /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/matcher.pyc /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/matcher.pyo /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/state.py /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/state.pyc /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/state.pyo /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/xtypes.py /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/xtypes.pyc /usr/lib/python${PYTHON_VERSION}/vendor-packages/xcbgen/xtypes.pyo 5. Packaging: 5.1. Existing packages: SUNWxwplt SUNWxwinc 5.2. New package: SUNWxcbgen 5.3. IPS Packaging: pkg:x11/library/libxcb pkg:x11/library/xcb-util --Boundary_(ID_btaErpGTLCR0j5pkYSsovw)-- From shawn.walker@oracle.com Thu Apr 1 17:01:52 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3201q93008139 for ; Thu, 1 Apr 2010 17:01:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3201oPa056260 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 1 Apr 2010 18:01:51 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L080020H2R3RV00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Apr 2010 17:01:51 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L08001J62R26L00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Apr 2010 17:01:51 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3201oG3012120 for ; Fri, 02 Apr 2010 00:01:50 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3201mXR009273 for ; Fri, 02 Apr 2010 00:01:49 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 132062981270166378; Thu, 01 Apr 2010 16:59:38 -0700 Received: from [10.7.250.95] (/10.7.250.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Apr 2010 16:59:37 -0700 Date: Thu, 01 Apr 2010 18:59:35 -0500 From: Shawn Walker Subject: Re: XCB (X Protocol C-Language Bindings) [PSARC/2010/109 FastTrack timeout 04/08/2010] In-reply-to: <4BB5232B.5070508@oracle.com> To: Alan Coopersmith Cc: PSARC-ext , Stefan Teleman Message-id: <4BB53367.9000303@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BB533ED.0095:SCFMA4539814,ss=1,fgs=0 References: <4BB5232B.5070508@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Thunderbird/3.0.3 Status: RO Content-Length: 2199 On 04/ 1/10 05:50 PM, Alan Coopersmith wrote: ... > 3.2. Interface Dependencies and Compatibility > > XCB's Interface Table is provided in the ARC Case Materials directory > [ xcb-interface-table.txt ]. > > Introducing XCB creates no additional run-time dependencies beyond > those already present in the X Consolidation. > > libX11 with XCB imports interfaces from: > > - libxcb.so.1 > > libxcb.so.1 imports interfaces from: > > - libXau.so.6 > - libXdmcp.so.6 > > Existing applications binding to Xlib's Committed Public Interfaces > [ libX11 ] are unaffected by the private implementations changes > created by XCB, and will continue to work as expected. Applications > consuming Xlib Project Private interfaces may break. XCB removes > a number of Xlib Project Private Interfaces from libX11 [ specifically > from Xtrans ]. Details are provided in the Interface Table. > > XCB creates a compile-time dependency on Python 2.6 [ SUNWPython26 ]. For pkg(5)-based systems, runtime/python-26 is the correct dependency name. > 4. Packaging > > This Case proposes the following packaging structure for XCB: > > 4.1. IPS Packaging: > > - The libraries, headers, and pkg-config discovery files for the main > xcb libraries, and the xcbgen developer tool will all be delivered > in pkg:x11/library/libxcb. Package FMRIs aren't valid without at least one leading slash: pkg:/x11/library/libxcb > - The libraries, headers, and pkg-config discovery files for the > additional libraries from the xcb-util collection will be delivered > in pkg:x11/library/xcb-util. pkg:/x11/library/xcb-util > In both packages, the headers, pkg-config files& xcbgen files > will all be part of the developer facet to avoid installation when > minimizing for non-development systems. Does the first package require the second package? That isn't clear from the case materials although it could be implied that the second package was an optional, developer package. In particular, Section 1 seems to indicate that a complete xcb installation requires both. -Shawn From Gordon.Ross@oracle.com Thu Apr 1 17:20:25 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o320KP2k008237 for ; Thu, 1 Apr 2010 17:20:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o320KOQW002645 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 1 Apr 2010 17:20:25 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0800H0B3M05Z00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Apr 2010 18:20:24 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L08007CM3M02NF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Apr 2010 18:20:24 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o320KNL6020048 for ; Fri, 02 Apr 2010 00:20:23 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o31F953W009691 for ; Fri, 02 Apr 2010 00:20:22 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 140255051270167611; Thu, 01 Apr 2010 17:20:11 -0700 Received: from [129.148.19.73] (/129.148.19.73) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Apr 2010 17:20:11 -0700 Date: Thu, 01 Apr 2010 20:20:10 -0400 From: Gordon Ross Subject: Re: XCB (X Protocol C-Language Bindings) [PSARC/2010/109 FastTrack timeout 04/08/2010] In-reply-to: <4BB5232B.5070508@oracle.com> To: Alan Coopersmith Cc: PSARC-ext Message-id: <1270167610.1063.33.camel@dell6300gwr> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BB53847.000B:SCFMA4539814,ss=1,fgs=0 References: <4BB5232B.5070508@oracle.com> Status: RO Content-Length: 455 > 2.1.1. Shared Libraries: > > /usr/lib/libX11-xcb.so.1 > > /usr/lib/libxcb.so.1 > /usr/lib/libxcb-composite.so.0 > /usr/lib/libxcb-damage.so.0 > /usr/lib/libxcb-dpms.so.0 > /usr/lib/libxcb-dri2.so.0 > /usr/lib/libxcb-glx.so.0 [ ... ] That's an awful lot of libraries to add to /usr/lib/. Do applications dlopen those names directly? If not, perhaps they could go in /usr/lib/libxcb/? From alan.coopersmith@oracle.com Thu Apr 1 17:25:44 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o320PhJr008304 for ; Thu, 1 Apr 2010 17:25:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o320Pgk8019238 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 1 Apr 2010 19:25:43 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0800D0R3UV2H00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Apr 2010 17:25:43 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0800MXB3UUZM70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Apr 2010 17:25:42 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o320PgCw014576 for ; Fri, 02 Apr 2010 00:25:42 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o320Peme007685 for ; Fri, 02 Apr 2010 00:25:41 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 132101841270167892; Thu, 01 Apr 2010 17:24:52 -0700 Received: from [129.145.155.53] (/129.145.155.53) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Apr 2010 17:24:52 -0700 Date: Thu, 01 Apr 2010 17:24:51 -0700 From: Alan Coopersmith Subject: Re: XCB (X Protocol C-Language Bindings) [PSARC/2010/109 FastTrack timeout 04/08/2010] In-reply-to: <1270167610.1063.33.camel@dell6300gwr> To: Gordon Ross Cc: PSARC-ext Message-id: <4BB53953.7080002@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BB53986.0003:SCFMA4539814,ss=1,fgs=0 References: <4BB5232B.5070508@oracle.com> <1270167610.1063.33.camel@dell6300gwr> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 1105 Gordon Ross wrote: >> 2.1.1. Shared Libraries: >> >> /usr/lib/libX11-xcb.so.1 >> >> /usr/lib/libxcb.so.1 >> /usr/lib/libxcb-composite.so.0 >> /usr/lib/libxcb-damage.so.0 >> /usr/lib/libxcb-dpms.so.0 >> /usr/lib/libxcb-dri2.so.0 >> /usr/lib/libxcb-glx.so.0 > [ ... ] > > That's an awful lot of libraries to add to /usr/lib/. > Do applications dlopen those names directly? If not, > perhaps they could go in /usr/lib/libxcb/? They mostly link directly against them, but they may dlopen. In any case, hiding them in a directory other than /usr/lib only introduces incompatibility with other platforms and violates the previous direction from ARC & management to make libraries with public interfaces directly available in the default path instead of hiding them in out of the way places like /usr/sfw/lib or its other obsolete brethren. /usr/lib is already full of libraries - another dozen or two more is barely noticable. -- -Alan Coopersmith- alan.coopersmith@oracle.com Oracle Solaris Platform Engineering: X Window System From stefan.teleman@oracle.com Thu Apr 1 21:47:57 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o324lvSe011272 for ; Thu, 1 Apr 2010 21:47:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o324luaw005573 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 1 Apr 2010 21:47:56 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0800107FZWW000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Apr 2010 22:47:56 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0800LG4FZVXV10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 01 Apr 2010 22:47:56 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o324ltna009591 for ; Fri, 02 Apr 2010 04:47:55 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o31L06HM006128 for ; Fri, 02 Apr 2010 04:47:54 +0000 (GMT) Received: from abhmt014.oracle.com by acsmt354.oracle.com with ESMTP id 140694291270183618; Thu, 01 Apr 2010 21:46:58 -0700 Received: from [10.7.250.112] (/10.7.250.112) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Apr 2010 21:46:57 -0700 Date: Fri, 02 Apr 2010 00:46:55 -0400 From: Stefan Teleman Subject: Re: XCB (X Protocol C-Language Bindings) [PSARC/2010/109 FastTrack timeout 04/08/2010] In-reply-to: <4BB53367.9000303@oracle.com> To: Shawn Walker Cc: Alan Coopersmith , PSARC-ext Reply-to: stefan.teleman@oracle.com Message-id: <4BB576BF.4070302@Oracle.COM> Organization: Oracle USA Corporation MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BB576FB.0037:SCFMA4539814,ss=1,fgs=0 References: <4BB5232B.5070508@oracle.com> <4BB53367.9000303@oracle.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090218) Status: RO Content-Length: 1385 Shawn Walker wrote: > pkg:/x11/library/libxcb > >> - The libraries, headers, and pkg-config discovery files for the >> additional libraries from the xcb-util collection will be delivered >> in pkg:x11/library/xcb-util. > > pkg:/x11/library/xcb-util > >> In both packages, the headers, pkg-config files& xcbgen files >> will all be part of the developer facet to avoid installation when >> minimizing for non-development systems. > > Does the first package require the second package? I thought it was very clear that xcb-util, being a collection of additional shared libraries importing and exporting XCB Interfaces, depend on the first package, which delivers libxcb.so.1. > That isn't clear > from the case materials although it could be implied that the second > package was an optional, developer package. In particular, Section 1 > seems to indicate that a complete xcb installation requires both. XCB-based applications only need the XCB shared libraries (the XCB run-time) to run. Therefore, they do not need header files, XML meta-programming schemas, or pkg-config files. Developers who wish to either - write new XCB extensions, or - write libraries or applications which consume pre-packaged XCB interfaces will need to install the developer facet. --Stefan -- Stefan Teleman Oracle Corporation stefan.teleman@Sun.COM From stefan.teleman@Oracle.COM Fri Apr 2 08:17:06 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o32FH6o8006589 for ; Fri, 2 Apr 2010 08:17:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o32FH2Nd022571 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 2 Apr 2010 08:17:06 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L090032794H4L00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 09:17:05 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L090083194GLK90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 09:17:04 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o32FH49g023566 for ; Fri, 02 Apr 2010 15:17:04 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o32FH2dp022048 for ; Fri, 02 Apr 2010 15:17:02 +0000 (GMT) Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 133350351270221385; Fri, 02 Apr 2010 08:16:25 -0700 Received: from [10.7.250.112] (/10.7.250.112) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Apr 2010 08:16:25 -0700 Date: Fri, 02 Apr 2010 11:16:23 -0400 From: Stefan Teleman Subject: Re: XCB (X Protocol C-Language Bindings) [PSARC/2010/109 FastTrack timeout 04/08/2010] In-reply-to: <4BB60547.6030702@oracle.com> To: Shawn Walker Cc: Alan Coopersmith , PSARC-ext Reply-to: stefan.teleman@Oracle.COM Message-id: <4BB60A47.8000703@Oracle.COM> Organization: Oracle USA Corporation MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BB60A6F.011E:SCFMA4539814,ss=1,fgs=0 References: <4BB5232B.5070508@oracle.com> <4BB53367.9000303@oracle.com> <4BB576BF.4070302@Oracle.COM> <4BB60547.6030702@oracle.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090218) Status: RO Content-Length: 1033 Shawn Walker wrote: > I asked if the *first* package (libxcb) *required* the second package > (xcb-util). It was already clear the second required the first. > However, your reply below seems to indicate the first package does not > require the second. If the first package required the second, and the second package required the first, XCB would have an internal circular dependency, and that would be a Bad Thing(TM), because circular dependencies in software architecture -- as a general rule -- are toxic, and it would have never passed muster either at XCB, or here. > So to be clear then, end-users would never need the libraries in the > proposed pkg:/x11/library/xcb-util package to run an application, only > developers? It is up to the application developer to create a direct binding dependency on a shared library from the xcb-util package. End-users might need (and probably *will* need) the shared libraries from both packages. --Stefan -- Stefan Teleman Oracle Corporation stefan.teleman@Sun.COM From shawn.walker@oracle.com Fri Apr 2 09:06:48 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o32G6mbG007606 for ; Fri, 2 Apr 2010 09:06:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o32G6m78015956 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 2 Apr 2010 09:06:48 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0900917BFBEO00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 09:06:47 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L09008DABFBJ400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 09:06:47 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o32G6ksi001013 for ; Fri, 02 Apr 2010 16:06:47 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o32FqD2W031983 for ; Fri, 02 Apr 2010 16:06:46 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 133384941270222446; Fri, 02 Apr 2010 08:34:06 -0700 Received: from [10.7.250.95] (/10.7.250.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Apr 2010 08:34:06 -0700 Date: Fri, 02 Apr 2010 10:34:04 -0500 From: Shawn Walker Subject: Re: XCB (X Protocol C-Language Bindings) [PSARC/2010/109 FastTrack timeout 04/08/2010] In-reply-to: <4BB60A47.8000703@Oracle.COM> To: stefan.teleman@oracle.com Cc: Alan Coopersmith , PSARC-ext Message-id: <4BB60E6C.5040703@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BB61616.00DE:SCFMA4539814,ss=1,fgs=0 References: <4BB5232B.5070508@oracle.com> <4BB53367.9000303@oracle.com> <4BB576BF.4070302@Oracle.COM> <4BB60547.6030702@oracle.com> <4BB60A47.8000703@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Thunderbird/3.0.3 Status: RO Content-Length: 1199 On 04/ 2/10 10:16 AM, Stefan Teleman wrote: > Shawn Walker wrote: > >> I asked if the *first* package (libxcb) *required* the second package >> (xcb-util). It was already clear the second required the first. >> However, your reply below seems to indicate the first package does not >> require the second. > > If the first package required the second, and the second package > required the first, XCB would have an internal circular dependency, and > that would be a Bad Thing(TM), because circular dependencies in software > architecture -- as a general rule -- are toxic, and it would have never > passed muster either at XCB, or here. That hasn't stopped other packages from being shipped that way, so I wanted to be clear. I'm glad to hear that isn't the case. >> So to be clear then, end-users would never need the libraries in the >> proposed pkg:/x11/library/xcb-util package to run an application, only >> developers? > > It is up to the application developer to create a direct binding > dependency on a shared library from the xcb-util package. End-users > might need (and probably *will* need) the shared libraries from both > packages. Thanks for the explicit clarification. -Shawn From john.fischer@oracle.com Fri Apr 2 09:42:05 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o32Gg5UZ008446 for ; Fri, 2 Apr 2010 09:42:05 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o32Gg1f1031054 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 2 Apr 2010 10:42:03 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0900J1JD23FF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 09:42:03 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L090080LD22IW20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 09:42:03 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o32Gg2iX008351 for ; Fri, 02 Apr 2010 16:42:02 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o32Gg04g015514 for ; Fri, 02 Apr 2010 16:42:00 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 133521811270226494; Fri, 02 Apr 2010 09:41:34 -0700 Received: from [10.7.250.80] (/10.7.250.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Apr 2010 09:41:34 -0700 Date: Fri, 02 Apr 2010 09:41:33 -0700 From: John Fischer Subject: Re: XCB (X Protocol C-Language Bindings) [PSARC/2010/109 FastTrack timeout 04/08/2010] In-reply-to: <4BB6108F.8060709@Oracle.COM> To: stefan.teleman@oracle.com Cc: Alan Coopersmith , PSARC-ext Message-id: <4BB61E3D.5000809@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BB61E5A.0037:SCFMA4539814,ss=1,fgs=0 References: <4BB5232B.5070508@oracle.com> <4BB604C3.6050105@oracle.com> <4BB6108F.8060709@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 2750 Stefan, I am good with most of the responses. I want to delve a little more into the first issue. 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 ]. 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. From stefan.teleman@Oracle.COM Fri Apr 2 12:50:35 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o32JoZ6o012177 for ; Fri, 2 Apr 2010 12:50:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o32JoYen011741 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 2 Apr 2010 14:50:34 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0900305LSAT700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 12:50:34 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L09003E6LS9D800@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 12:50:33 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o32JoXYK014416 for ; Fri, 02 Apr 2010 19:50:33 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o32FmAaj028627 for ; Fri, 02 Apr 2010 19:50:30 +0000 (GMT) Received: from abhmt005.oracle.com by acsmt355.oracle.com with ESMTP id 142674891270237761; Fri, 02 Apr 2010 12:49:21 -0700 Received: from [10.7.250.112] (/10.7.250.112) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Apr 2010 12:49:21 -0700 Date: Fri, 02 Apr 2010 15:49:19 -0400 From: Stefan Teleman Subject: Re: XCB (X Protocol C-Language Bindings) [PSARC/2010/109 FastTrack timeout 04/08/2010] In-reply-to: <4BB61E3D.5000809@oracle.com> To: John Fischer Cc: Alan Coopersmith , PSARC-ext Reply-to: stefan.teleman@Oracle.COM Message-id: <4BB64A3F.6030903@Oracle.COM> Organization: Oracle USA Corporation MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BB64A88.00F2:SCFMA4539814,ss=1,fgs=0 References: <4BB5232B.5070508@oracle.com> <4BB604C3.6050105@oracle.com> <4BB6108F.8060709@Oracle.COM> <4BB61E3D.5000809@oracle.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090218) Status: RO Content-Length: 4446 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 stefan.teleman@Oracle.COM From john.fischer@oracle.com Mon Apr 5 15:56:35 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o35MuZJJ029323 for ; Mon, 5 Apr 2010 15:56:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o35MuZQG004206 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 5 Apr 2010 17:56:35 -0500 (CDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0F00B05EEBFH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 05 Apr 2010 16:56:35 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0F0062QEEAW420@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 05 Apr 2010 16:56:34 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o35MuYr5021427 for ; Mon, 05 Apr 2010 22:56:34 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o35MZlNS025031 for ; Mon, 05 Apr 2010 22:56:33 +0000 (GMT) Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 138357221270508134; Mon, 05 Apr 2010 15:55:34 -0700 Received: from [10.7.250.61] (/10.7.250.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Apr 2010 15:55:33 -0700 Date: Mon, 05 Apr 2010 15:55:32 -0700 From: John Fischer Subject: Re: XCB (X Protocol C-Language Bindings) [PSARC/2010/109 FastTrack timeout 04/08/2010] In-reply-to: <4BB6108F.8060709@Oracle.COM> To: stefan.teleman@oracle.com Cc: Alan Coopersmith , PSARC-ext Message-id: <4BBA6A64.6000004@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BBA6AA1.01B8:SCFMA4539814,ss=1,fgs=0 References: <4BB5232B.5070508@oracle.com> <4BB604C3.6050105@oracle.com> <4BB6108F.8060709@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 4016 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 > stefan.teleman@Sun.COM > From stefan.teleman@oracle.com Mon Apr 5 16:02:43 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o35N2hEY029580 for ; Mon, 5 Apr 2010 16:02:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o35N2gqW028546 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 5 Apr 2010 17:02:42 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0F00F07EOI8P00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 05 Apr 2010 16:02:42 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0F004M2EOHL5A0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 05 Apr 2010 16:02:42 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o35N2fV9004514 for ; Mon, 05 Apr 2010 23:02:41 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o35EvEcH010850 for ; Mon, 05 Apr 2010 23:02:40 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 138368081270508514; Mon, 05 Apr 2010 16:01:54 -0700 Received: from [10.7.250.112] (/10.7.250.112) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Apr 2010 16:01:54 -0700 Date: Mon, 05 Apr 2010 19:01:52 -0400 From: Stefan Teleman Subject: Re: XCB (X Protocol C-Language Bindings) [PSARC/2010/109 FastTrack timeout 04/08/2010] In-reply-to: <4BBA6A64.6000004@oracle.com> To: John Fischer Cc: Alan Coopersmith , PSARC-ext Reply-to: stefan.teleman@oracle.com Message-id: <4BBA6BE0.3000802@Oracle.COM> Organization: Oracle USA Corporation MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BBA6C11.003C:SCFMA4539814,ss=1,fgs=0 References: <4BB5232B.5070508@oracle.com> <4BB604C3.6050105@oracle.com> <4BB6108F.8060709@Oracle.COM> <4BBA6A64.6000004@oracle.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090218) Status: RO Content-Length: 367 Thank you for the comments! --Stefan ----- John Fischer wrote: > 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 -- Stefan Teleman Oracle USA Corporation stefan.teleman@Oracle.COM From alan.coopersmith@oracle.com Wed Apr 7 10:13:43 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o37HDgsJ016162 for ; Wed, 7 Apr 2010 10:13:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o37HDfI0020301 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 7 Apr 2010 12:13:42 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0I00F0JNUU1A00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Apr 2010 10:13:42 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0I003EKNUTGQF0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Apr 2010 10:13:41 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o37HDfv7021832 for ; Wed, 07 Apr 2010 17:13:41 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o37HDeOI022562 for ; Wed, 07 Apr 2010 17:13:40 +0000 (GMT) Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 154829641270660415; Wed, 07 Apr 2010 10:13:35 -0700 Received: from [129.145.155.53] (/129.145.155.53) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 10:13:35 -0700 Date: Wed, 07 Apr 2010 10:13:34 -0700 From: Alan Coopersmith Subject: Re: XCB (X Protocol C-Language Bindings) [PSARC/2010/109 FastTrack timeout 04/08/2010] In-reply-to: <4BBA6A64.6000004@oracle.com> To: PSARC-ext Cc: stefan.teleman@oracle.com Message-id: <4BBCBD3E.7090503@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BBCBD44.01AA:SCFMA4539814,ss=1,fgs=0 References: <4BB5232B.5070508@oracle.com> <4BB604C3.6050105@oracle.com> <4BB6108F.8060709@Oracle.COM> <4BBA6A64.6000004@oracle.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 175 This case was approved by PSARC today during ARC business. -- -Alan Coopersmith- alan.coopersmith@oracle.com Oracle Solaris Platform Engineering: X Window System