Official protest against bug 1060 / was: Re: Away for a fewdays..

[Daniel Stone]

On Fri, Aug 27, 2004 at 12:09:44AM +0200, Roland Mainz wrote:
> Owen Taylor wrote:
> > the Xprint server is a separate server.
> 
> Yes and no. The Xprint server can be seperate but there is no need for
> that. At least HP has an unified Xserver for both video and printing.

Yes, but it is actually a separate server.

> >    So, make them separate packages, distributed on X.org, but
> >    not part of the main tree.
> 
> Xprint _IS_ part of the main tree and was added with X11R6.4. And in
> those days there was a _CONSENS_ to add it. You cannot simply undo that
> or kick Xprint out of the main tree (yes, I know, lots of RedHat staff
> like blizzard at redhat.com, caillon at redhat.com or Mike Harris want to see
> it dead and pester around whereever they can... ;-( ).

It's not just Red Hat, actually. But anyway.

> Like Xvfb, Xnest and Xvnc the Xprt server needs huge parts of the
> Xserver infratructure and it is very difficult to seperate that stuff
> out. And sticking the Xprint server into a seperate tree would also mean
> that all new extensions and fixes need to be ported to the Xprint tree,
> too - which would result in a huge amount of unneccesary maintaince work
> when new stuff gets added (XST comes in mind) or stuff gets updated
> (like XRENDER). All Xservers - and this includes Xorg, Xnest, Xvfb and
> Xprt - should be kept together in one tree to avoid that the common
> parts of these Xservers gets out of sync.
> One of the goals behind the creation of the Xorg foundation was to have
> ONE common, central source repository for X11 to avoid that the codebase
> of the various vendors get more and more out of sync. Ripping out some
> Xservers which do not "fit" into the political plans of some vendors
> will contradict these goals.

The way you put it, X.Org Foundation is at direct odds with
modularisation.

> Removing the Xprint client side extension library is also not neccesary
> nor something I would recomment for the simple reason: The API is stable
> (AFAIK since 10 or more years) and we have no plans to change that API
> in the near future. Moving it into a seperate project will cause more
> havoc than neccesary.

Er, why would it cause any havoc? You just move it back out to
xprint.org or whereever, like it was before. I can see why you would
think it had negative side effects, but not any havoc as such.

> >  - Similarly, Xaw could be broken out into a separate package,
> >    that people who were excited about developing could develop
> >    as they see fit.
> > 
> >    The problem with breaking out Xaw is definitely the toy
> >    and demo apps that come with the X server. They'd have
> >    to be broken out as well.
> 
> That sounds like the X tree modularisation project - which is something
> for the far future. Nothing which can be done for X11R6.8 or within this
> year.

Far future? Not even close.

I've been running modular libraries on my desktop for quite some time
(as well as a modular server, modular-built fonts, et al), and many
distributors have been seriously investigating it. I don't see how this
is some futuristic bluesky idea, when it works today.

> > But short term, I think the need is to come to a consensus and
> > release the tree. I don't really have a say in this, but
> > here's the argument I'd make:
> > 
> >  - Adding Xprint support to Xaw really isn't the sort of change
> >    that should have gone into the tree without active agreement;
> >    passive "nobody objected" isn't enough.
> 
> Again, various annoucements were made. And most of the people related to
> Xaw/Xaw3D I knew about were informed about the change and even people
> outside that circle. This includes people like Kaleb Keithley (who wrote
> parts of Xaw and Xaw3D), D. J. Hawkey Jr. (the current Xaw3D
> maintainer), Egbert Eich (Xorg board member), Alan Coopersmith (Xorg
> arch member) and many others.
> 
> And: Could you please list the message ids of the Xorg arch board
> discussion which approved the "Tooltip" widget in libXaw ? AFAIK this
> was silently added without any approval by the Xorg arch board and
> neither was it annouced.
> If the same rules and same conditions which were used as justification
> to back out the XawPrintShell code apply to the "Tooltip" widget issue
> then that code needs to be backed out, too.

Did the Tooltip widget introduce a dependency on another library; one
which many people don't want to install?

> >    If Xaw was a separate project, that would be a different
> >    issue ... people would have an opt-out by simply using an
> >    older Xaw without the new additions.
> 
> Erm... one of the goals of adding XawPrintShell to likXaw/Xaw3D was to
> _gurantee_ that the new widget doesn't break binary compatibility to
> older versions of libXaw.so.7.
> Yes, there is the option to simply bump the major version number of the
> shared library (e.g. libXaw.so.8) but then the whole effort and (mainly)
> the testing was for the trashcan (after the whole disaster and the
> debate here at am at the point to consider that as an option... but
> somehow I start to feel sorry with the poor guys who did all the
> testing).

We all feel for people who have done work for nothing, because it sucks.
But it's not a sign of a conspiracy, the apocalypse, or anything else;
in this case, the only pointer is to a small breakdown in communication.

> >  - In my opinion, conditionalizing the Xaw/Xprint changes and
> >    noting that they are experimental in the release notes
> >    is a similar to what we could do with a modularized tree,
> >    it indicates:
> > 
> >      "these changes don't reflect the technical consensus of the
> >       community, but they are interesting work being done
> >       within the X.org umbrella"
> 
> The same applies to the "Tooltip" widgets. And likely a couple of other
> changes to libXaw made between X11R6.6 and Xfree86V4.4.0RC2. Noone
> objected or complained about these additions nor was AFAIK the Xorg arch
> board involved. Nor were any weired release notes written which
> indicated that this code is "experimental" or "... failed to have a
> technical consensus...".

Again, these didn't make Xaw's build conditional on that of another
library, which many would love to be able to disable.

> >    So, I'd suggest the changes should be included with the
> >    necessary liberal application of #ifdefs.
> 
> There are more options than that:
> 1. Leave the code as it was originally designed. It's the same design
> choice as it was made for version 2 of the Motif toolkit and NOONE ever
> complained about that change or the added dependicy to libXp.so.
> And noone ever complained about the detail that libXaw depends on the
> SHAPE extension (which cannot be turned off without breaking libXaw,
> too).

(Consider me complaining about any dependency on the Xp library.)

> 2. Link libXp.a _statically_ into libXaw (the complains about the size
> increment aren't valid - as I wrote a while ago we're talking about 25Kb
> on x86 - which is _litte_ compared to the size increment of libX11
> between X11R6.6 and current X11R6.8 trunk) and only build the print
> support in the demo applications if a new switch has been set to |YES|

Linking statically? NO NO NO NO NO.

Not only is this woefully ugly, there are many technical issues (e.g.
PIC) that imake is guaranteed to get wrong.

> 3. Bump libXaw's shard library major version number to "8". That would
> give people the choice to ship both the old versions - and optionally
> the new version

Shipping one version of libXaw is enough, let alone three.

> 4. |#ifdef| out the XawPrintShell support in libXaw but keep the symbols
> intact. Missing print shell support in libXaw is indicated via setting
> the Xt class pointer of XawPrintShell to |NULL|.

This wouldn't be the worst thing ever.

> 5. Load libXp.so dynamically at runtime using |dlsym()|

Which still makes Xp a dependency.

> 6. Back out XawPrintShell completely (and the whole Tooltip code, too.
> And don't forget to make SHAPE extension support in libXaw optional
> (which will require a version bump of the shared library version number
> to "8", too))

Why would making a feature optional necessitate a soversion bump?

> 7. Split XawPrintShell into a seperate library. (But I explained already
> in detail elsewhere why this is not possible: Again, for reference:
> -- snip --
> I already explained that (in release-wrangers I think) splitting
> XawPrintShell into a seperate library will cause significant PAIN for
> the distributors since they have an additional shared library to support
> - which somehow collides with the argument that XawPrintShell should be
> split off due resource reasons.

Let me tell you, as a distributor, that that's not pain at all. Given we
already have close on 60 or whatever it is libraries, I really don't
care about one more. And as for the 'support' argument -- so what? We're
still supporting the exact same code.

> And AGAIN: Splitting XawPrintShell into a seperate library will make it
> IMPOSSIBLE that the other widgets in libXaw can properly interact with
> the print shell. Please do not look at libXaw, look at Motif and it's
> applications and how the printing stuff is implemented there. Then you
> can imagine in which hell we suddenly end when XawPrintShell is placed
> in a seperate library.

Isn't this just an argument against bad design (e.g. Motif), not putting
stuff in separate libraries?

> I think this is pretty much clear. And rules out this option.
> ).

Er, no.

> Comments:
> - Personally I would favor [1] since it causes zero pain for both users
> and programmers.
> - Options [4] and [5] are UGLY and scream for trouble

Four, five, or six are the most appealing to me.

> >    If that isn't technically feasible though, I'd point out that
> >    you can always add later, but removing once you've released
> >    is a *lot* harder.
> 
> Right. But the XawPrintShell API is mainly a clone (with minor
> enhancements) of the XmPrintShell widget class which is stable since at
> least Motif release 2.1. As long as noone changes the Motif print API in
> an incompatible way there will be no need to change the XawPrintShell
> API. The XawPrintShell API is rock-stable.
> And it's waiting for integration into the Xorg repository since a long
> time. It ONLY missed X11R6.7 because I didn't had the time to do so and
> was quickly added after the tree was open again for new commits.

I understand these arguments, but you keep holding up how much work
everyone has done and how sorry we should feel for them, when people are
raising valid technical objections to the code in question, is
distracting the issue. Please don't do this.

> P.S.: Just to quote it here: the backout of XawPrintShell and in the X11
> demo application did some damage to the demo applications - partially
> non-printing related fixes were backed out, too... ;-(

Er, if you're arguing for more scrutiny of patches, sure. I think what
you're saying here is 'be careful when you back this Xprint stuff out',
not 'don't back this Xprint stuff out'.