No Subject

You wrote the code, so I take your word for it.  But did you have to  
use the Xpm library to do the parsing for you, or did you find it  
possible to do it correctly by hand ?  Would you be willing to write an  
XPM parser skeleton which does not use any extra libraries or X or UN*X  
specific system facilities for use in all the clients ?  (No, that was  
not a rethorical question).  If you are, I'd be very happy to make Xpm  
the image standard in the second draft of the protocol.

> And while the data is not compact for XPM files, it is very
> compressible. You (Carl) have been talking about how the links wil be
> compressing the text information.  The XPM data will be compressed
> just as nicely.

That's true.  Compactness I thought ranked fairly low on the list of  
reasons for not using Xpm.

> Also, clients probably should not be requesting new image files all
> that often.

I'm not so sure.  Probably it would be a good idea to distribute the  
clients with some of the couple dozen most commonly used images (i.e.  
all that appear in the initial city) already pre-cached to make the  
first startup faster.

> [A few more agreeable paragraphs deleted]

> The XPM library source is quite small (less than a 100K tar gzipped
> file).  And for clients, much of that code would not be needed (ie,
> reading from certain specific things or writing would not be needed.)

100 kBytes tarred and gzipped might be small compared to the server,  
but it may very well dwarf the size of source for most clients.  I  
really do think that is too big to require the whole library to be  
included with every client.

> I think you (Carl) are greatly over estimating how difficult it would
> be to write a program that converts from XPM format.

Maybe -- I'm always willing to take the word of the people who will  
do/did something for how easy it was going to be/was.

But for example the fact that Xpm uses named colors (rather than RGB  
values) alone causes a lot of problems.  Sure, X systems have the same  
standard list of colors (with some local extensions) and the library  
calls to handle it, so it is nothing to worry about.  But what about  
other systems ?  When I ported Emacs 19 to NeXTstep this fact added  
some 25 kBytes to the installation and that was just because NS already  
had a system of color naming and I just needed to convert from the X to  
the NS color table format.  But what about systems which don't having  
any naming system at all ?  Are you going to write the source the code  
for them ?

	Carl Edman