Re: A strawman proposal for X.org & XFree86.org

Vadim Plessky wrote:
> On Sunday 30 March 2003 03:31, Alan Coopersmith wrote:
> |  Vadim Plessky wrote:
> |  > While many points in this proposal are valid, there are some *untouched*
> |  > questions:
> |  >
> |  > 1) wether Sun and other X.org members take *as commitment* duty to
> |  > develop support (or backport existing code from XFree86 CVS) for
> |  > existing and upcoming XFRee86 extensions, like RENDER, Xr, Xc?
> |
> |  Each individual member will support or not support the XFree86 extensions
> | as their business needs see fit.  This is the situation with every X
> 
> That's fine with me.
> But:  *why* we should bother than in creating common codebase ("reference 
> implementation") between X.org and XFree86.org?

To make it easier and more likely that the other vendors will use XFree86 and
contribute back to it.  The code base is already common - the point is to keep
it that way and use resources more effectively than maintaining two copies
of the same core code base.

> XFree86's "business needs" are in Linux (*BSD, UNIX) Desktop, with majority of 
> users splitted between KDE and GNOME and some minority using *pure X* with 
> selected number of pure X applications.
> 
> If we take traditional UNIX vendors (Sun, HP, Digital Alpha/now part of HP, 
> IBM, SGI) - their priorities are in *server* market.
> So, basically they need pure X to run apps like Management Console, to 
> configure Firewall, etc.

I can't speak for the other vendors, but GNOME & desktops (workstations & thin
clients) are definitely much higher on Sun's X priority list than servers.  Sun
may have other priorities on servers, but there isn't much call for X there,
while it's really hard to sell a SunBlade workstation or SunRay thin client 
without it.

> I don't know what XIE, PEX, and Xprint :-)

Extensions that have been in the X.org code base for years that many 
distributors don't bother to support.  (XIE & PEX are generally recognized as
part of the "fat" that you want to trim these days as no one really uses them
anymore.  Xprint is somewhat used - it's a seperate X server that "displays"
by creating postscript and pcl print jobs, for simple addition of printing to
an X application using the same API, much like MacOS & Windows printing.
Mozilla can print to it, as can some versions of OpenOffice.)

At some point, someone thought each one was necessary, but no one made all
vendors support them if they saw no need to.

> Render support is needed for anti-aliased fonts & icons, Xr/Xc support is 
> needed for SVG (and later - PS and PDF) support.

You can get anti-aliasing, SVG, PostScript & PDF without any of those.  They
just provide different ways to do it, that may be hardware accelerated.

> Som epeople mentioned that we need to through away Xlib in favour of Xr/Xc,

I've not seen that and I from what I've seen Xr/Xc aren't supposed to be a
complete replacement for Xlib - just a different rendering model.  (There's
much more to Xlib than just the drawing routines.)

> |  > Without such commitment from X.org members *in written*, with timetable
> |  > to complete the port specified, further discussions about merging X.org
> |  > and XFree86.org make no sense, IMHO.
> |
> |  Why should you dictate how the vendors choose to spend their resources? 
> 
> Because we either need *the standard*, or we don't need "standards body" at 
> all.

No standards body that I'm aware of dictates that implementors must implement
the standard on a given timetable.  Standards define what should happen when
your implementation claims to apply to the standard - if you don't implement it,
you simply don't claim to meet that standard.

> I mean, we should make it clear:  either you commit yourself to implementing 
> all necessary extensions (not only Render, but Xr/Xc/RandR as well) to X on a 
> timely basis, or we do not allow you to participate in further development of 
> standards.

Who decides which extensions are "necessary" and what constitutes "timely"?
Many of the old-school Unix vendors release their OS'es on a 2-3 year release
cycle - are you going to demand they change their entire release model just to
meet what you consider is timely?  Even RedHat has adopted a 12-18 month release
schedule for their "Enterprise Workstation" OS - is that too slow for you?

And when does your clock start ticking?  When the extension is finished?  When
is that?  All of the ones you mention appear to still be under active 
development.  Keith just added animated cursors to Render in November, revising
the protocol again.  How closely do you want to mandate vendors try to catch a
moving target?

> | The discussion here is about how best to manage the two open source
> | implementations, the X.org sample implementation & XFree86, which is a
> | superset of the X.org. What the vendors choose to do with the results is
> | their business.  You have no written commitment with timetable from Redhat,
> | SUSE, FreeBSD, or anyone else to support Xr & Xc, so why should Sun, IBM,
> | HP, etc. be any different?
> 
> RedHat packages latest XFree86 (4.3.0), Mandrake 9.1/Cooker also comes with 
> XFree86 4.3.0.  Don't know about SuSE.
> So, I guess RedHat and Mandrake already committed theirself.
> Don't know about FreeBSD - but I guess it would come with latest stuff in 6 
> months or so.

Do you have written committments from each of these vendors or are you just
assuming based on prior action?  I doubt any company or open source OS release
project in the world is willing to have you dictate their schedules for them,
nor should they.

gcc now has C99 support - but you don't see them telling everyone in the world
they must convert all their C code immediately or lose all ability to
participate in gcc development, but that seems to be the attitude you're taking.

> But I am wondering wether we should keep compatibility with previous X 
> versions?

Unless there is a very strong reason to break compatibility, then yes,
keeping compatibility is a very good thing for everyone.

> I think you don't want to drop some legacy code in X fo Solaris, right?

We do drop legacy code from Solaris as we determine it is no longer worth the
cost of support.  We already dropped the previously mentioned PEX extension
years ago since it was clear everyone chose OpenGL for 3D rendering instead.

> Drop xterm, twm, old X toolkits, PCF/BDF fonts, etc.

And what about the thousands of people still using them?  I know many people
who would be incredibly upset if we tried removing xterm - they use it every
day and don't want the bloat of gnome-terminal.

> We need just basic X APIs, sufficient for GTK and Qt toolkit to be 
> operational.
> Motif support, etc. should be dropped ASAP.

So everyone with existing software should throw it away or never upgrade to
a new version of XFree86?

-- 
	-Alan Coopersmith-      [email protected]
	 Sun Microsystems, Inc.   -   Sun Software Group
	 Quality, Integration, & Customer Success (QICS)
	 Platform Globalization Engin. - X11 Engineering