From sac-list-owner Fri Jun 15 17:30:03 2001 Date: Fri, 15 Jun 2001 17:25:40 -0700 (PDT) From: John McKernan Subject: PSARC/2001/060 libXpm Image Format library To: psarc@sac.eng.sun.com Cc: alan.coopersmith@sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: bibvBOS634IVvl3ITr9WWg== Content-Length: 6466 I am sponsoring this fast-track for Alan Coopersmith. The timer expires 6/22/01. This fast-track is requesting approval for a micro release binding. 1. Introduction 1.1. Project/Component Working Name: libXpm Image Format library 1.2. Name of Document Author/Supplier: Alan Coopersmith, Solaris X11 Development Group 1.3. Date of This Document: 06/08/01 1.4. Name of Major Document Customer(s)/Consumer(s): PSARC, PCSC 2. Project Summary 2.1. Project Description This project proposes to integrate the Xpm freeware libraries and programs for manipulating & converting image file formats into the X consolidation. This software has become a defacto standard in the Unix and Linux communities, and is used by a wide variety of programs, including some shipped by Sun. Unfortunately, Sun has previously shipped the libraries as project private or Sun private interfaces, causing unnecessary duplication, and user frustation when they discover the libraries are present, but they have to compile their own versions to get header files. We hope that by ensuring this software is included as part of Solaris X11 that at least some of the existing duplicate copies can be removed and future proliferation prevented. In addition, it will make it easier to install third-party software that depends on this software, including almost all freeware window managers and desktop environments. 2.2. Risks and Assumptions libXpm is a particularily stable freeware library. The latest release of libXpm was made in March 1998, and the latest change that could affect compatibility was the addition of items to a data structure in 1996. The last change to the file format was made in 1991, and the file format has since been adopted by the Open Group as part of the CDE standard. 3. Business Summary 3.1. Problem Area This provides a single point of support for the XPM image formats for all Solaris customers. 3.2. Market/Requester Long established image library included in other UNIX variants and used by many programs (ex: netscape6). 3.3. Competitive Analysis XFree86 includes libXpm and the cxpm and sxpm programs. This is the X11 software included in virtually all Linux distributions, as well as the freeware BSD distributions. Compaq & SGI include libXpm on their FreeWare CDs for Tru64 & Irix. IBM includes libXpm in the AIX5L "Toolbox for Linux Applications." 3.4. Opportunity Window/Exposure GNOME, Netscape 6.x, & the Linux Compatibility Projects all need this library in Solaris 9, and if we don't deliver it for all to share we risk getting 3 more private copies on the system. 4. Technical Description libXpm: Current release: 3.4k Home page: http://www-sop.inria.fr/koala/lehors/xpm.html Author/maintainer: Arnaud Le Hors License: BSD / X Consortium style license As of Solaris 8 copies of part or all of libXpm are included in: - Motif 1.2 (libXm.so.3) - Motif 2.1 (libXm.so.4) - CDE 1.4 (libDtSvc) - Solaris 8 Freeware Companion CDs - Sun/Forte Workshop (XEmacs) - "Exploring the GNOME Environment" (GNOME 1.4 public Early Access) The XPM format & libXpm API's are defacto industry standards, and are used by a wide variety of programs. The XPM format is also the standard icon/pixmap format for CDE and is officially defined in the CDE standards documents. This project will deliver the libXpm library, the cxpm & sxpm programs, and documentation for all three with the Solaris X11 packages, making as few changes as possible from the public releases. Sun is currently working with the X.org Group to integrate XPM into the X standards & sample implementation. Since that is not yet done, we have chosen a stability level of "Evolving", with the intention of upgrading to "Standard" once a formal standard is in place. Deliverables by package: SUNWxwplt: /usr/openwin/lib/libXpm.so.4 /usr/openwin/bin/cxpm /usr/openwin/bin/sxpm Symbolic links: /usr/openwin/lib/libXpm.so.4.11 -> libXpm.so.4 /usr/openwin/lib/libXpm.so -> libXpm.so.4 SUNWxwplx: /usr/openwin/lib/sparcv9/libXpm.so.4 Symbolic links: /usr/openwin/lib/sparcv9/libXpm.so.4.11 -> libXpm.so.4 /usr/openwin/lib/sparcv9/libXpm.so -> libXpm.so.4 SUNWxwinc: /usr/openwin/share/include/X11/xpm.h SUNWxwrtl: Symbolic links: /usr/lib/libXpm.so.4.11 -> /usr/openwin/lib/libXpm.so.4 /usr/lib/libXpm.so.4 -> /usr/openwin/lib/libXpm.so.4 /usr/lib/libXpm.so -> /usr/openwin/lib/libXpm.so SUNWxwrtx: Symbolic links: /usr/lib/sparcv9/libXpm.so.4.11 -> /usr/openwin/lib/sparcv9/libXpm.so.4 /usr/lib/sparcv9/libXpm.so.4 -> /usr/openwin/lib/sparcv9/libXpm.so.4 /usr/lib/sparcv9/libXpm.so -> /usr/openwin/lib/sparcv9/libXpm.so SUNWxwman: /usr/openwin/share/man/[s]man1/cxpm.1 /usr/openwin/share/man/[s]man1/sxpm.1 /usr/openwin/share/man/[s]man4/xpm.4 SUNWxwpmn: Man pages for /usr/openwin/share/man/[s]man3/ to cover the functions listed in the exported interfaces table below. Imported Interfaces: XPM File Format Standard Open Group CDE Standard Exported Interfaces: Programs: cxpm Evolving See man page in case directory sxpm Evolving See man page in case directory APIs: Evolving See API doc in case directory libXpm.so.4 Evolving See API doc in case directory including the following exported functions: XpmReadFileToImage, XpmReadFileToPixmap, XpmWriteFileFromImage, XpmWriteFileFromPixmap, XpmCreateImageFromData, XpmCreatePixmapFromData, XpmCreateDataFromImage, XpmCreateDataFromPixmap, XpmReadFileToData, XpmWriteFileFromData, XpmCreateImageFromBuffer, XpmCreatePixmapFromBuffer, XpmCreateBufferFromImage, XpmCreateBufferFromPixmap, XpmReadFileToBuffer, XpmWriteFileFromBuffer, XpmFreeAttributes, XpmAttributeSize, XpmFreeExtensions, XpmFree, XpmGetErrorString, XpmLibraryVersion, XpmReadFileToXpmImage, XpmWriteFileFromXpmImage, XpmCreateXpmImageFromData, XpmCreateDataFromXpmImage, XpmCreateXpmImageFromBuffer, XpmCreateBufferFromXpmImage, XpmCreateImageFromXpmImage, XpmCreateXpmImageFromImage, XpmCreatePixmapFromXpmImage, XpmCreateXpmImageFromPixmap, XpmFreeXpmImage, XpmFreeXpmInfo 5. Reference Documents 1. cxpm man page (in case directory). 2. sxpm man page (in case directory). 3. libXpm API doc (in case directory). From sac-list-owner Sun Jun 17 08:31:42 2001 Date: Sun, 17 Jun 2001 08:32:53 -0700 (PDT) From: "Joseph E. Kowalski III" Subject: Re: PSARC/2001/060 libXpm Image Format library To: psarc@sac.eng.sun.com, John.McKernan@sfbay.sun.com Cc: alan.coopersmith@sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GRoDmN7CAe8W9YY4mQZY7w== Content-Length: 855 > From: John McKernan ... > Sun is currently working with the X.org Group to integrate XPM into > the X standards & sample implementation. Since that is not yet done, > we have chosen a stability level of "Evolving", with the intention of > upgrading to "Standard" once a formal standard is in place. ... > Exported Interfaces: > > Programs: > cxpm Evolving See man page in case directory > sxpm Evolving See man page in case directory > > APIs: > Evolving See API doc in case directory > libXpm.so.4 Evolving See API doc in case directory From reading the text, this sounded like an obvious place to use the new External classification. Was is considered? I guess the right answer to this depends alot on how close this is to being standardized by the X consortium. - jek3 From sac-list-owner Mon Jun 18 12:05:17 2001 Date: Mon, 18 Jun 2001 12:07:35 -0700 (PDT) From: Ralph Campbell Subject: Re: PSARC/2001/060 libXpm Image Format library To: psarc@sac.eng.sun.com, John.McKernan@sfbay.sun.com Cc: alan.coopersmith@sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: e3WTte18gpmFmSaUM9uTYA== Content-Length: 111 Is /usr/openwin/* the right install location? What about the case: 2001/104 Move of /usr/openwin to /usr/X11? From sac-list-owner Mon Jun 18 12:31:20 2001 Date: Mon, 18 Jun 2001 12:32:23 -0700 (PDT) From: Alan Coopersmith Subject: Re: PSARC/2001/060 libXpm Image Format library To: psarc@sac.eng.sun.com, John.McKernan@sfbay.sun.com, Ralph.Campbell@eng.sun.com Cc: alan.coopersmith@sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ZrNmmzgkjKDNDAdDbSNmtg== Content-Length: 800 >Date: Mon, 18 Jun 2001 12:07:35 -0700 (PDT) >From: Ralph Campbell >Subject: Re: PSARC/2001/060 libXpm Image Format library >To: psarc@sac.eng.sun.com, John.McKernan@sfbay.sun.com >Cc: alan.coopersmith@sfbay.sun.com >MIME-Version: 1.0 >Content-MD5: e3WTte18gpmFmSaUM9uTYA== > >Is /usr/openwin/* the right install location? >What about the case: 2001/104 Move of /usr/openwin to /usr/X11? > The project to move from /usr/openwin to /usr/X11 has been put on hold at this time and will probably not happen for Solaris 9. If/when it does happen, these files will be moved to /usr/X11 with the rest of the X11 software. -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - Software Systems Group Cust. Advocacy & Tech Services: X11 Engineering From sac-list-owner Mon Jun 18 13:21:56 2001 Date: Mon, 18 Jun 2001 13:23:00 -0700 (PDT) From: Alan Coopersmith Subject: Re: PSARC/2001/060 libXpm Image Format library To: psarc@sac.eng.sun.com, John.McKernan@sfbay.sun.com, Joseph.Kowalski@eng.sun.com Cc: alan.coopersmith@sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 77BQYsECTOXn3AInHvgtGA== Content-Length: 1811 >Date: Sun, 17 Jun 2001 08:32:53 -0700 (PDT) >From: "Joseph E. Kowalski III" > >> From: John McKernan >... >> Sun is currently working with the X.org Group to integrate XPM into >> the X standards & sample implementation. Since that is not yet done, >> we have chosen a stability level of "Evolving", with the intention of >> upgrading to "Standard" once a formal standard is in place. >... >> Exported Interfaces: >> >> Programs: >> cxpm Evolving See man page in case directory >> sxpm Evolving See man page in case directory >> >> APIs: >> Evolving See API doc in case directory >> libXpm.so.4 Evolving See API doc in case directory > >From reading the text, this sounded like an obvious place to use the >new External classification. Was is considered? I guess the right answer >to this depends alot on how close this is to being standardized by the >X consortium. We considered External but determined it wasn't quite the correct fit for this case. From what I understand, for an External interface, the primary goal is maintaining the same API as the external version, even if this means breaking backwards compatibility. Our intention is instead to provide a stable API that other Solaris projects can rely on, and which places continued compatibility at a higher level of importance than matching changes in the external version. (In this particular case, we don't think there will be much conflict, since there is far too large a body of existing work dependent on the current API for gratitious changes to be accepted by the community.) -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - Software Systems Group Cust. Advocacy & Tech Services: X11 Engineering From sac-list-owner Mon Jun 18 13:35:50 2001 Date: Mon, 18 Jun 2001 13:32:48 -0700 (PDT) From: Joseph Kowalski Subject: Re: PSARC/2001/060 libXpm Image Format library To: psarc@sac.eng.sun.com, John.McKernan@sfbay.sun.com, Joseph.Kowalski@eng.sun.com, Alan.Coopersmith@Sun.COM Cc: alan.coopersmith@sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: gNpieHNiBfbDBR3B6bmfAQ== Content-Length: 3008 > From: Alan Coopersmith ... > >Date: Sun, 17 Jun 2001 08:32:53 -0700 (PDT) > >From: "Joseph E. Kowalski III" > > > >> From: John McKernan > >... > >> Sun is currently working with the X.org Group to integrate XPM into > >> the X standards & sample implementation. Since that is not yet done, > >> we have chosen a stability level of "Evolving", with the intention of > >> upgrading to "Standard" once a formal standard is in place. > >... > >> Exported Interfaces: > >> > >> Programs: > >> cxpm Evolving See man page in case directory > >> sxpm Evolving See man page in case directory > >> > >> APIs: > >> Evolving See API doc in case directory > >> libXpm.so.4 Evolving See API doc in case directory > > > >From reading the text, this sounded like an obvious place to use the > >new External classification. Was is considered? I guess the right answer > >to this depends alot on how close this is to being standardized by the > >X consortium. > > We considered External but determined it wasn't quite the correct fit for this > case. From what I understand, for an External interface, the primary goal is > maintaining the same API as the external version, even if this means breaking > backwards compatibility. Our intention is instead to provide a stable API that > other Solaris projects can rely on, and which places continued compatibility at > a higher level of importance than matching changes in the external version. > > (In this particular case, we don't think there will be much conflict, since > there is far too large a body of existing work dependent on the current API > for gratitious changes to be accepted by the community.) Evolving may be the right answer, but let me take this a bit further: 1] Mark Himelstein is pushing against the type of classification assignment you are proposing. This isn't architecture. Its just a heads-up. 2] You state: "Our intention is instead to provide a stable API that other Solaris projects can rely on, and which places continued compatibility at a higher level of importance than matching changes in the external version." This can be obtained with "External" for other Solaris Products by using internal agreements. It is the commitment to the external consumer which should make the determination between "External" and "Evolving". 3] If you believe #2, then the interesting question becomes "What do you intend to do if the remote possibility happens and libXpm evolves incompatibly between now and acceptance as a standard? My only point is that using "External" + a set of internal agreements gives you more wiggleroom with the external consumers should a remote possibility happen. The cost is making sure that you've enumerated the internal consumers. As with so many things, this isn't a clear choice. Most of this is just stuff for you to consider. - jek3 From sac-list-owner Mon Jun 18 17:53:40 2001 Date: Mon, 18 Jun 2001 17:49:13 -0700 (PDT) From: John McKernan Subject: Re: PSARC/2001/060 libXpm Image Format library To: psarc@sac.eng.sun.com, Joseph.Kowalski@eng.sun.com Cc: alan.coopersmith@sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tSsj2K28XRRVp2MvCp+d/w== Content-Length: 4029 >X-Authentication-Warning: engmail4.Eng.Sun.COM: noaccess owned process doing -bs >X-Authentication-Warning: engmail4.Eng.Sun.COM: noaccess@localhost didn't use HELO protocol >Date: Mon, 18 Jun 2001 13:32:48 -0700 (PDT) >From: Joseph Kowalski >Subject: Re: PSARC/2001/060 libXpm Image Format library >To: psarc@sac.eng.sun.com, John.McKernan@sfbay.sun.com, Joseph.Kowalski@eng.sun.com, Alan.Coopersmith@Sun.COM >Cc: alan.coopersmith@sfbay.sun.com >MIME-Version: 1.0 >Content-MD5: gNpieHNiBfbDBR3B6bmfAQ== > > >> From: Alan Coopersmith >.. >> >Date: Sun, 17 Jun 2001 08:32:53 -0700 (PDT) >> >From: "Joseph E. Kowalski III" >> > >> >> From: John McKernan >> >... >> >> Sun is currently working with the X.org Group to integrate XPM into >> >> the X standards & sample implementation. Since that is not yet done, >> >> we have chosen a stability level of "Evolving", with the intention of >> >> upgrading to "Standard" once a formal standard is in place. >> >... >> >> Exported Interfaces: >> >> >> >> Programs: >> >> cxpm Evolving See man page in case directory >> >> sxpm Evolving See man page in case directory >> >> >> >> APIs: >> >> Evolving See API doc in case directory >> >> libXpm.so.4 Evolving See API doc in case directory >> > >> >From reading the text, this sounded like an obvious place to use the >> >new External classification. Was is considered? I guess the right answer >> >to this depends alot on how close this is to being standardized by the >> >X consortium. >> >> We considered External but determined it wasn't quite the correct fit for this >> case. From what I understand, for an External interface, the primary goal is >> maintaining the same API as the external version, even if this means breaking >> backwards compatibility. Our intention is instead to provide a stable API that >> other Solaris projects can rely on, and which places continued compatibility >at >> a higher level of importance than matching changes in the external version. >> >> (In this particular case, we don't think there will be much conflict, since >> there is far too large a body of existing work dependent on the current API >> for gratitious changes to be accepted by the community.) > >Evolving may be the right answer, but let me take this a bit further: > > 1] Mark Himelstein is pushing against the type of classification > assignment you are proposing. This isn't architecture. Its just > a heads-up. > > 2] You state: > > "Our intention is instead to provide a stable API that other Solaris > projects can rely on, and which places continued compatibility at > a higher level of importance than matching changes in the external > version." > > This can be obtained with "External" for other Solaris Products by > using internal agreements. It is the commitment to the external > consumer which should make the determination between "External" > and "Evolving". > > 3] If you believe #2, then the interesting question becomes "What do > you intend to do if the remote possibility happens and libXpm > evolves incompatibly between now and acceptance as a standard? > >My only point is that using "External" + a set of internal agreements >gives you more wiggleroom with the external consumers should a remote >possibility happen. The cost is making sure that you've enumerated the >internal consumers. As with so many things, this isn't a clear choice. The Xserver engineering team prefers the Evolving stability level for libXpm. We believe that libXpm is different from many other open source libraries in that it is an older library that has had a stable API for many years. The Xserver engineering team commits to doing the work to minimize any changes in the libXpm API for our external customers. However, we really believe that significant change in the libXpm API before it is standardized is very unlikely. John From sac-list-owner Wed Jun 20 11:09:07 2001 Date: Wed, 20 Jun 2001 11:04:36 -0700 (PDT) From: John McKernan Subject: PSARC/2001/060 libXpm Image Format library To: psarc@sac.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LiSmYc/s2pAwORvkzquhCQ== Content-Length: 85 PSARC/2001/060 (libXpm Image Format library) was approved at today's PSARC meeting.