Re: XFIXES extension proposal

What XFree *really* needs is much more data compression when sending data to
a remote display. It seems XFree is being used more and more for diskless
clients and to display remote screens. The X protocol uses alot of Bandwidth
when dealing with *alot* of clients.
----- Original Message -----
From: "Keith Packard" <[email protected]>
To: <[email protected]>
Cc: "Keith Packard" <[email protected]>
Sent: Saturday, November 30, 2002 10:19 PM
Subject: Re: [Xpert]XFIXES extension proposal


> Around 3 o'clock on Dec 1, James Hawtin wrote:
>
> > The only problem with the fixes extension will people use it, as they
> > will have to write the code twice so it supports "legancy" ie not
Xfree86
> > systems. (thinking of selection tracking here)
>
> That's been the argument against such extensions over the last 15 years,
> and it's certainly valid as far as it goes, but I think we can now look
> toward more rapid adoption of extensions in the general population,
> certainly rapidly enough to provide incentive for application developers
> to support the new mechanisms in addition to the old.
>
> > As kludges exist for some of these fixes, a compatibility library could
be
> > made so people who wrote code in the "new" way, would have some kind of
> > support on other systems, but still could write things "clean", in the
> > case of selection tracking, it would do the polling, but return events
as
> > if the XFIXES was there.
>
> Perhaps that would be possible at the toolkit level, but down at the
> protocol library level, there's no flow of control to manage timeouts and
> the like.  As XFree86 doesn't really have control over the dominate
> toolkits, we'll have to see what those groups manage to implement,
> although we might give them some suggestions.
>
> Keith Packard        XFree86 Core Team        HP Cambridge Research Lab
>
>
> _______________________________________________
> Xpert mailing list
> [email protected]
> http://XFree86.Org/mailman/listinfo/xpert
>