> We wanted to belive XFree86 justice, fairness, and democracy, but we
> might be wrong.

X has never been designed democratically.  Our current leadership is 
relatively benign, though, and can be induced to listen to reasoned 
arguments.

And while the release of a version of X including native utf8 support in X
lib would have been probably a bad idea many years ago, the reality is that
today XFree86 is again an open source project and I, among others, have
been trying to guide the development and design into a more public
environment.

Part of that design methodology involves having people submit code that may
not yet have reached rough concensus among the participants.  Heck, I built
a completely new library in the two weeks before the release; I'll bet very
few people even glanced at the source code.  It may well affect i18n more
than Xutf8*.  No one blinked.

An important distinction between the current XFree86 design method and the
old X consortium method is that existing implementations of standards in
the public code may well change.  But I don't propose that we edit the
actual standard without significant concensus and agreement on whether
those changes are worthy of codification.  

In the bad old days, we'd struggle for months (or years) developing a new
standard, agree upon it, standardize it and then finally ship brand new
code to the world.  How many standards developed that way have survived the
test of time?  XIE?  PEX?  Even, to some extent, the XIM/XOM architecture,
which required significant revision after initial standardization.

An important role model here is the IETF -- IETF standards are based on 
rough concensus and *running code*.  This means you can't have a standard 
without a fully functional implementation that has seen real usage.  A 
cogent discussion of the merits of any new standard can never reach 
closure until a reasonable implementation has been in use for some time.

It is interesting that the utf8 functions have been in XFree86 CVS for 
nearly a month, and only the pending release of 4.0.2 has raised eyebrows 
enough to start a (somewhat heated) debate of their merits.  I'm pleased
that people are passionate about the topic and I hope the discussion 
continues to clarify the situation.

I believe that the people involved can reach a rough concensus at some
point so that we can finish the work by revising the standards in
appropriate ways.  If the concensus is that Utf8 functions don't belong in
Xlib, then they'll get ripped out of the implementation and never see the
light of a standards document.  

But if the value of native utf8 support inside Xlib is judged to be higher
than the cost of non-Xmb capable applications, then Xutf8 functions will be
documented and standardized like any other piece of the X library.

Personally, I'll try to remain impartial -- I'm currently opposed to both
Xutf8 and XIM/XOM. If I had my way, I'd rip them both out and stick them
into separate libraries that toolkits and applications could use or not as
they choose.  I don't expect to prevail in that view, but at least I'm not 
biased in the current discussion...

keithp@keithp.com	 XFree86 Core Team		SuSE, Inc.