Re: About our effort at NoMachine

> Sender: [email protected]
> From: Alan Cox <[email protected]>
> Date: Wed, 26 Mar 2003 12:45:08 -0500 (EST)
> To: [email protected]
> Cc: [email protected] (Gian Filippo Pinzari)
> Subject: Re: [forum] About our effort at NoMachine
> -----

> What I would love to see in X11 is conditional streams. When you throw
> a command at a shell for example you can say
>
>         "Do X, Y, Z , ... "
>
> but also
>
>         Do X, Y, Z, ..."
>
> and bracketed sets of these
>
>         Do  (Do X, Y, Z stopping on fail)  (Do A, B, C stopping on fail)
>
> but stop on a failure. That gives you the ability to do more than just
> batching, since you can batch a sequence of commands for the general
> case and respond to the failure. My gut feeling (and I've not been
> doing analysis unlike you folks) is that this would improve things
> immensely for startup
>

No, that isn't the common problem in the packet traces we've begun
staring at, from what we see; though maybe the Qt and GTK developers
might have a different perspective.

There are places in the core protocol which are unnecessarily painful
for toolkit developers, as various common events generate errors in
the X protocol that should have just generated return status.  If
I got a chance to participate in the design over again of both the
X core protocol and Xlib, I'd do things somewhat differently.

Bart Massey has been working on a different wire protocol interface
(think replacement for Xlib, though structured differently); we've certainly
talked quite a bit on how to do it differently (and he has been, avoiding
my mistakes; time will tell what mistakes he's made :-)).


> > 7) image transport is a real issue, whether for glyphs or other images.
> > This is in part due to image sizes having grown due to greater depth
> > (most people have 32 bits/pixel these days). So besides compressing
> > glyphs, having the window system able to better
> > take images in pretty native formats would be a serious win for alot of
> > applications.
>
> It is also due to the inability to do long term caching of images in
> the server/on disk _between_ server runs on low bandwidth links
>

Yup: this is what the Web does extensively.  The trick is that round trips
cost you dearly, and how do you know what is cached?

If you want to go to really low bandwidth, that is clearly a likely win,
and proxy pairs can certainly share such information.

X does work pretty well over broadband for most applications, and
moderate amounts of work can improve it greatly.
The question in my mind, given the Web's existance and network
technology improvement is how far in that direction to go.
But we want to make sure to only improve the local case (the most common),
and never make that worse.


> > The trap to avoid here is the XIE slippery slope, and focus on image
> transport,
> > rather than image processing.
>
> Given there are well understood processes for image compression and well
> understood processes for lossless pixmap compression why do you say this.
> I'm curious ? Do you oppose the ability to send jpeg for example, or the
> way XIE kind of grew beyond a way to transport images into a whole
> nightmare of processing features ?

The latter: XIE became an image processing swiss army knife too complicated
for anyone to understand,  rather than a really useful tool.
                                - Jim

--
Jim Gettys
Cambridge Research Laboratory
HP Labs, Hewlett-Packard Company
[email protected]