Re: Pixmaps, and client/server startup

["Carl Edman" <>]

 writes:
> It would be nice if, on startup, servers sent their client a bunch of
> version headers. Especially about the pixmap-type data.
> 

>      Server                             Client
>                                     Hello 
>   Hello Client. This is  Sound Enabled Color Enabled 

>   (Disabled is default, ...   Enabled..    so never bother to
>                      say "Disabled")

Why should the server care what kind of sound/color/a.s.o. the client  
has ?  A client without sound capability will just never request any  
sound files from the server.  A black and white client will just  
convert the color images to black and white images when it receives  
them.

> At any rate, you could have a "standard" distribution, and tons of
> specialized ones. The beauty of it is that 1)  None will conflict
> with each other 2) There's no wondering about whether you have the
> "proper" pix 3) You only have to go through the excruciatingly long
> download setup once.

No, that means that the client has to download the complete set of  
images every single time any of its servers changes even a single of  
its pixmaps.  What in the world is the win in this over a scheme in  
which the server just assumes that the client has the named bitmap and  
it is up to client the client to request the bitmap for the server on  
an as-needed basis ?

> Ideally, though, we would send the bitmaps/pixmaps in some
> independant format, and its up to the client how it stores them. I
> personally suggest Xpm gzipped "files", seeing as how the source to
> both of them is freely available, so it will be "easily"
> incorporatable into most any setup.

Yes, the source is available but how much overhead do you add to  
clients which run on machines which quite possible are not X (and so  
very likely wont have Xpm) or not even UN*X (and so will have a hard  
time installing gzip and executing it as a subprocess) ?  This is  
particularily questionable as gzip is not even very effective on image  
data.  My vote for the format would be something much simpler like raw  
ppm.  You can write a parser which translates it into virtually any  
native format in a page or two.  If you really want to compress it, use  
something simple but effective on image data like run-length encoding.

	Carl Edman