On Tue, 2005-04-26 at 11:28 +1000, Drew Parsons wrote: > I'm hoping my xprint won't be an unbearable thorn in Debian's Xorg > side. I've been waiting to hear from upstream what the long term plans > are for Xprint as a separate source from X.org, but haven't received > any definite plans yet. For myself, I consider Xprint a legacy solution to support applications which require it but to push future application development to the cairo +CUPS model which provides a modern drawing model, wider text layout support and better printer interaction based on the nearly universally (OS X, Windows, Linux) supported IPP printer protocol. With announcements like last weeks cairo-based Mozilla port, and the plans to migrate Gtk+ to the cairo API, it makes a lot of sense for X.org to make sure that Xprint doesn't become wired into existing tools in a way that makes it impossible to deprecate it at some point in the future. We had a similar issue with Xmu where this widely used library caused unintentional dependency on the now deprecated Xt library. Transitioning applications from Xmu to the subset Xmuu library still hasn't happened, so many applications end up linking in Xt just because they use some modest Xmu functionality. In contrast, XIE and PEX were both easy to remove from distributions because no standard (xdpyinfo, etc) applications referenced them. > If it turns out that upstream favours consolidating the Xprint source > only with the X.org, without the separate development that's happened > till now at xprint.mozdev.org, then the logical thing would be for me > to join the X Strike Force, with responsibility for the area that > packages Xprint. But I figure we'll build that bridge when we come to > it. Modular X development may enable a greater separation between display services and Xprint. > > > In the long run, of course, the monolithic sample implementation tree will > > cease to exist. > > The curious thing here with regard to Xprint, is that upstream has been > holding discussions with other X.org hackers over whether Xprint runs > best as a stand-alone server, or whether a unified print+display server > is a better idea. There are 3 alternatives: > 1) separate servers (the current situation) > 2) unified server run separate on different displays (one for video, one for print) > 3) unified server, just the one running which handles both video and print requests. Running a unified display/print service in the same address space seems foolish to me; the display server requires tremendous priviledge while the Xprint server communicates with many external applications and should run with as limited a priviledge as possible. This argues strongly for separate processes. Xprint also requires code inside the X server which is not needed by a display server, making it unreasonable to try to support both functions from the same binary images, which indicates that we should use separate programs as well. However, Xprint continues to share some source code with the display server, which might seem to encourage integration of Xprint with the display server source package. The amount of shared code is modest, and hasn't significantly changed (except for display-specific extensions) in a number of years (Xprint supports X as of about 13 years ago), making it less necessary to share. > It's not clear yet which version X.org will end up with. Version 2 > kind of makes sense to me, sharing as much code as possible between the > different kinds of server. But Version 3 is being considered favourably. We shouldn't let Roland Mainz and Sun Microsystems dictate the Debian packaging architecture in this case; security and support considerations encourage a wide separation in this case. I would like to see a world where no Xprint packages needed to be loaded on a machine which didn't have any Xprint services running. -keith
Attachment:
signature.asc
Description: This is a digitally signed message part