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

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?
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.

| vendor, including those who already ship off the XFree86 code base, and the
| way it should be.  Several vendors, including Sun & XiG (who is not an
| X.org member), have chosen already to port RENDER to their
| non-XFree86-based X servers, presumably because they determined there was
| sufficient customer demand for RENDER at this point.  If Xr & Xc similarly
| prove themselves, vendors will again have to decide whether the cost of
| adding support is more or less than the cost of losing customers who demand
| the support.  X.org is not requiring every X or XFree86 vendor to ship &
| support every single extension in the X.org codebase - would you think it
| fair to require everyone to commit to supporting XIE, PEX, and Xprint?

I don't know what XIE, PEX, and Xprint :-)
Render support is needed for anti-aliased fonts & icons, Xr/Xc support is 
needed for SVG (and later - PS and PDF) support.
Som epeople mentioned that we need to through away Xlib in favour of Xr/Xc, or 
at least to port Xlib so that it would using Xr/Xc with accelerated RENDER 
ext.
We need to put Xr/Xc support in basic toolkit libraries - Qt and GTK.
And later to get it to upper level - KDE and GNOME.
But what toolkit developers say at a moment: "as Xr/Xc not available on other 
X implementations (except XFree86), we can't use due to interoperability 
issues"

|
|  > 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.
Besides, bug companies do not understand "kind speaking", you need to speak to 
them on thier language.
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.
Again: it's up to X.org members to do whatever they want.
But if you want cooperation with XFree86 - you need to listen to us, and toi 
accept that XFree86 playing major role in modern X development.

| 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.

Don't get me wrong: I vote for *one* OpenSource implementation of X.
But I am wondering wether we should keep compatibility with previous X 
versions?
I think you don't want to drop some legacy code in X fo Solaris, right?
But most Linux users do not need legacy apps and old code, users request to 
trim bloat from X, make more frequesnt releases and reduce distribution size.
That's somewhat opposite with X.org members, IMO.
Can someone speak on X.org position on this?

|
|  > 2) there is nothing said about trimming X codebase, and in particular -
|  > eliminating support for PCF and BDF fonts in favour of Freetype backend
|  > and TTF fonts with embedded bitmaps.
|  > Many open-source developers are concerned with XFree86 codebase size,
|  > and they expect trimming fat from codebase (and not merging with
|  > X11R6.7)
|
|  XFree86 already contains all of X11R6.6 - there's not a ton of new fat in
|  X11R6.7 that's going to bloat XFree86.  In any case, those concerns are
| outside the scope of this proposal - the proposal is about determining how
| technical decisions and changes to the code will be made, not about
| predetermining the results of those decisions.

Yes, I agree with you.
We should create comitte ASAP which would take decision *what* parts of 
current X11R6.6 or upcoming X11R6.7 are irrelevant fo open-source 
users/distribution, and drop those parts immediately, for the next XFree86  
dot release.
X.org should decide wether they want open-source develoipers to lead X 
developemtn in the future.
If leading role of XFree86 is accepted - than X.org should follow Xfree86 in 
trimming old code from sourcebase, that's it.
Do we agree here?

|
|  (I am a bit confused though - if you are so worried about reducing the
| size of X, why are you also so insistent on increasing it with Xr, Xc,
| etc.?)

Drop xterm, twm, old X toolkits, PCF/BDF fonts, etc.
We need just basic X APIs, sufficient for GTK and Qt toolkit to be 
operational.
Motif support, etc. should be dropped ASAP.
Check out XFree86 codebase - and compare to real world apps what is used.

|
|  > 3) my experience of talking to engineers/sales&marketing people in
|  > couple of "leading UNIX vendors" shows that people from those companies
|  > are very proud with their "in-house" UNIX implementations, and mostly
|  > consider open-source software as a joke.
|  >
|   > Therefor, I doubt that X.org memebers would accept your proposal .
|
|  I'm fairly sure every single one of those Unix vendors that ships an X
| server is based on the X.org open source implementation already.  The X.org
| members have been giving money for years to support further development of
| the X.org implmentation as open source.  I don't think you'll find the
| resistance you expect.  (I know the leading UNIX vendor I work for is
| heavily involved in many open source projects, and does not consider it a
| joke.)

-- 
Best Regards,

Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
http://svgicons.sourceforge.net