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

[Jim Gettys]

Roland,

To begin with, we made the best call given we were unable to
talk to you due to circumstances beyond our (or your) control.

On Fri, 2004-08-20 at 19:35, Roland Mainz wrote:
> Jim Gettys wrote:
> > To begin with, I'm sorry we were not aware of the situation
> > earlier, and we need to work out a process so that this can get
> > handled sooner.
> > 
> > The large issue in my mind (personally) is the introduction of a new
> > significant size library dependency into Xaw, without the provision
> > to make it optional in the build.
> 
> The library dependicy is NOT significant, neither on x86, ARM nor on
> SPARC. The libXp.so library is very small and adds no compliciated
> dependicies. And the interface is stable since at least X11R6.4. How
> many years are that... ten ?
> 
> > Some of us work on footprint sensitive devices where adding
> > more code isn't a viable option. (nor do we have printers anywhere
> > nearby our iPAQ's).
> 
> Erm... remember that the server side of Xprint is just a simple Xserver
> ?

Which I don't have space for.

> Two years ago we demonstrated at the University Giessen that Xprint is
> VERY well suited for PDAs since all memory intensive stuff is done on
> the server side - which can be accessed via _remote_ X11 on a seperate
> machine.

Doesn't help my user base: neither Qt (Opie) or GTK+ (GPE) are
Xt based.

> 
> > I personally don't want to have to have an Xmu/Xmuu situation
> > have to develop for the library, to avoid picking up the depencency,
> > to recover space we literally don't have.
> 
> We are talking about less than 25KB of code on x86, on ARM Thumb it's
> even smaller. There are bigger things to complain about than a
> self-contained X11 extension library which has no other dependicies than
> libc, libX11 and libXext (which are always loaded anyway).
> And libXp.so is likely loaded anyway by other applications, too. You are
> worrying about the wrong things. Or at least about the wrong library:
> Between X11R6.0 and X11R6.7 libX11 grew by a few _hundred_ kilobytes.
> libXp.so is only a fraction of one _hundred_ kilobyte.

Yes, and I've managed to get much of that bloat back out; some of those
changes are in the modular tree, so you may not have been aware
of them. The question in this case, is where the burden of effort 
should lie. You do make the case it is much smaller than I realized.

(BTW, strongarm doesn't have thumb, so given my current build
environment, that doesn't help, unfortunately).

>  
> > So some of us would have to do additional work to remove the
> > dependency; I believe that it is incumbent on you, the person adding
> > functionality, to make it possible to build without the requirement
> > of picking up the dependency.
> 
> What about turning off the building of libXaw-based applications then ?

With it packaged into Xaw, if a user loads any such application,
they are forced into the dependency, a dependency that no-one was
unfortunately aware of until you were unavailable.  This means that
any/all existing applications pick up the dependency if that
widget is added to the library.

The bigger issue than size, or modularity, or whether we should be
maintaining Xt based clients in our code base, or any of the
other reasons is that there is *no* community consensus around 
Xprint.  Lacking this consensus, making it required
would be a mistake. Many people have strong opinions that
it is the wrong long term way to go. (myself included, to be 
completely frank). The fact that neither GTK+ nor Qt have 
adopted it makes clear the lack of consensus.

We *also* have strong opinions that people should be able to get their
code out, so that (eventually) competition in open source can make 
clear which way things should go. So we *really* do want to see your
work on Xprint available, and appreciate the hard work you have
put in on it to make it viable, which it has not been in the past.

So we are open to any solution (and held open the bugzilla bug
to enable do so even to the last possible moment, on the hope
you might become available), in which Xprint is
optional.  Making the toolkit widget a separate library has
that property. In your previous mail you said this won't work,
care to explain why?  Is there something that we, without
understanding Xprint intimately as you do, are missing?
                               Regards,
					- Jim