xtrans

Stuart Anderson anderson at netsweng.com
Fri May 20 07:13:02 PDT 2005


On Fri, 20 May 2005, Nathanael Nerode wrote:

> Keith Packard wrote:
>> There's no real need -- xtrans cannot be used by any package which it
>> doesn't know about.  Check out Xtrans.h; each user of xtrans has custom
>> code in that file -- one for Xlib, one for the Xserver, XIM, Font
>> server, font library, ICE, LBX.
>>
>> Xtrans is a spectacular example of encapsulation gone wrong...

Yes. The original design was for a single library that had the ability
to parse an endpoint description at runtime, and do the right thing.
Somewhere along the integration w/ X11R6-beta, it got turned into a
compile time configurable things that used ifdefs to make decisions.

To make matters worse, it has "evolved" over the decade since then.

> Hmm.  This should probably have been sliced differently.
> * The TRANS_SERVER and TRANS_CLIENT ifdefs are so pervasive that the files
>  should perhaps be broken into client-only, server-only, and
>  both-client-and-server pieces.  Not to mention TRANS_REOPEN.

Someone decided that it was bad having the unused code (server stuff in
a client & vice-versa) linked into a server or client. As a shared
library, this small expense in code space probably could have been justified.
Also, 10 years ago, a few K of object size was much more significant
that it is today.

> It's very very tempting to suggest that each user be given its own copy,
> at least as an interim measure.

One warning here: That's the situation that existed in X11R5 that Xtrans
was designed to solve. There was similar/duplicate code, complete with lots
of OS specific #ifdefs scattered over many places in the tree.


                                 Stuart

Stuart R. Anderson                               anderson at netsweng.com
Network & Software Engineering                   http://www.netsweng.com/
1024D/37A79149:                                  0791 D3B8 9A4C 2CDC A31F
                                                  BD03 0A62 E534 37A7 9149


More information about the xorg-modular mailing list