Re: Maintaining HTTP connections...

Christian L. Mogensen (mogens@CS.Stanford.EDU)
Wed, 27 Jul 1994 18:06:54 -0700 (PDT)

Daniel W. Connolly writes:

> [Sorry... I took a thread from the www-speed list and cross-posted
> it to www-talk. I gues I didn't give enough background while I
> was at it.]

> Yes... a compound document architecture would do the world a lot
> of good. But it's complex and messy. In the mean time, doing
> multiple HTTP transactions over one TCP connection is a cheap
> hack with big potential win.

[munch munch]

> Rather than multiple GETs in a request, we try multiple requests
> in one TCP session. Hmmm... a lot of headers get repeated.
> Perhaps this is what simon was saying about Accept: headers.

There is something similar to this in the EIT/CommerceNet SHTTP spec
that is worth looking at. The idea of several encapsulated requests
mirrors what you are saying. (and yes - the redundant headers become
annoying - maybe they can be moved into the enclosing MULTIPART ?

> Ah... but consider a collection of 1000 chemistry documents that
> have little alpha's and beta's all over them. A client downloads
> chemistry-font.xbm once, and caches it for the whole session.

How about downloading each char once and caching each char separately?
Lots of initial up front costs, but doable now...

<Img src=/chem/alpha.gif><img src=/chem/omega.gif> etc.

> Ok... so use xbm, or any other bitmap format. I don't care. The point
> is that you can GET one image with a whole bunch of glyphs in it.

Well - no!
This is a general problem - how to distribute font info reliably.
Postscript is one answer - except it isn't used by any rendering
system except the NeXT. ATM fonts are ok - but X and most Macs
don't deal. Fonts are a problem. PDF tries to deal with it, but
isn't widespread (yet).

> No, no, no. It's used just like IMG SRC=... is used, for example,
> by the LaTeX2HTML translation tools -- to incorporate little images
> into the flow of text as a hack for characters that are not part
> of HTML.

Ok - I see your point about sending over one bitmap and then indexing into
it - however, as you also say - moving clients over is a hassle.

The best bet would be to put each char in a separate bitmap (ie:
one img per character) - So the initial loading cost is high, but
falls as the client cache kicks in. Plus: It works now - no changes.

Now if multiple gets per connection were fixed - it still works, but

Now if someone can implement better font rendering hints into HTML
and the browsers, we're much better off...