Re: HTTP: T-T-T-Talking about MIME Generation

In message <ab1685b2030210040a79@[]>, Mitra writes:
>One thing to consider (not that i think this is a bad idea) is that often
>the objects being sent along are images leading to two non-optimisations.
>1) Mime encoding is going to roughly double the number of bytes sent

Hello? Mime encoding adds a few bytes between objects for the boundary.

HTTP is 8-bit clean, after all. No base64 needed.

>2) By explicitly sending them every time, the server wont allow the client
>to cache the images, so for example the stupid blue ball for a "bullet"
>will get send a zillion times.

This is a very good point.

The other point is that it is sufficiently expensive to deploy MGET or
multipart/* over HTTP at this point that we might as well bite the
bullet and do something long-term like Session Control Protocol (which
meshes nicely with some security protocols like Secure Sockets Layer).

Deploying MGET/multipart looks to me like:

	* Somebody hacks support into NCSA HTTPD (last I heard, that
	source code is not to enhancement-friendly. No offense intended.)

	* Somebody figures out how to manage these multipart files: do
	you cache them? create them with a cron job?

	* Bill Perry shows us how it's done with the emacs w3 browser.

	* Henric adds support in libwww 3.x (which is perhaps sufficiently
	different from 2.x that the lynx/chimera guys can't upgrade without
	a lot of pain and hassle?)

	* Somebody hacks support into NCSA Mosaic. (libwww in NCSA Mosaic
	bears little if any resemblance to CERN's libwww by now.)

	* A few information providers maybe start using it
		(It's 3 months into the future by now)

	* Other browser/server impelementors get pressured into adding

Meanwhile, commercial folks are implementing HTTP-NG at lightning
speed. Six months from now, all the major vendors are doing
interoperable compression and encryption over something like SCP or
SSL (not to mention strong authentication).

In short: 'taint worthit.

I'd rather see more effort spent on

	(1) Specifying existing practice on HTTP/1.0, keeping an eye
	on opportunities to gateway/cache/proxy out of HTTP and into
	next-generation protocols.

	(2) Carefully crafting HTTP-NG using an interface definition
	language like ASN/1 or OMG's IDL, so that it can be used
	with various transports and protocols. (ILU! ILU! ILU! ahem...)

	(3) Investigating some name service and replication strategies
	so that links that we write today will continue to work tomorrow.

	(4) Coordinating implementation efforts, and working on
	a common base of reusable code.


Received on Thursday, 15 December 1994 16:25:17 UTC