Re: Pixmaps, and client/server startup

[Philip Brown <>]

>>>>[From Carl Edman]

    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 ?

As I mentioned, at at least has to be on a per-server basis, because
custom servers will have conflicting names for things.
You could throw in a part of the protocol,
"Send me pixmaps which have been changed since XXX".

Kinda sucky, though, as that means the server has to keep dates on every
pixmap.

Far simpler just to say "If outdated, update"

Plus, what if some pixmaps got updated to "nifty k00l knew 1s", and the
client doesn't know about it?  The user would never know to request the
new version.

THe client should take care of this automatically.

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

SOURCE, my friend, means that they can simply incorporate the gzip
(or rather, just the gunzip ) source directly into their client,
eliminating the need for a subprocess. Ditto for Xpm stuff.


    This is particularily questionable as gzip is not even very effective
    on image data.

Actualy, it's EXTREMELY effective on Xpm data, last time I recall using
it.

But it would be not very useful if the protocol only allowed for
downloading images at a time. It would really shine if block pixmap
updating were allowed.


    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.
    

Run-length encoding doesn't work too well on xpm's, I think. Not because
offormat, but because of type of data,