On Thu, May 03, 2001 at 02:05:55AM -0500, Brandon wrote:
>
> > No, I'm saying that FProxy should do the right thing w/r/to a web browser.
> > Other clients may or may not need to perform automatic decompression at
> > layer X. How can adding a feature to FProxy break all existing clients?
>
> You're not proposing a feature addition to FProxy, you're proposing a new
> metadata field and an addition to FProxy. Here's the metadata of two
> files:
>
> ContentType=text/plain
>
> ContentType=text/plain
> ContentEncoding=gzip
>
> Read by an old client, these look the same. The second is actually a gzip
> file. Therefore old clients will be broken with respect to handling files
> that contain the ContentEncoding field since they don't know what that is.
Brandon, what old clients? The old clients that support the new metadata
standard?
> On the other hand, you could have
>
> ContentType=text/plain
>
> ContentType=application/x-gzip
>
> This is backwards compatible with old clients. They simply can't tell the
> difference between a zip file and a text file which was automatically
> zipped on insert, which is much more reasonable than thinking that zip
> files are actually text files.
>
> > You're right. That is so much simpler and transparent than, say, adding
> > a ContentEncoding field to the Info metadata.
>
> I didn't say it was simpler, I said it was the right way, based on several
> principles.
>
> First don't break old clients when you can help it.
Again, what old clients?
> Second don't add things to the specifications because it's useful or
> natural for one of the implementations. As far as I can tell, the
> arguement for adding the metadata field is because it makes sense in
> FProxy since you just pass it through to the browser and then the browser
> handles content encoding. All other clients are now required to handle
> content encoding.
Your way makes it impossible for the client to know the actual MIME type
of the file.
> Doing it the other way, dispensing with the notion of encoding as
> separate from file types and just having some clients which automatically
> turn text/HTML files into zips and automatically unzip text/HTML files
> allows it to be a totally optional added feature rather than yet another
> thing which a client must do in order to be a properly functioning Freenet
> client.
>
> It's important to keep the metadata specification itself simple and to
> keep the number of *required* things that a Freenet client must comply to
> at a minimum.
Would this be better?
ContentType=application/x-gzip
ContentDecoding=text/html
--
# tavin cole
#
# "The process of scientific discovery is, in effect,
# a continual flight from wonder."
# - Albert Einstein
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
