> I hate to say it but your wrong Brandon. The content-type of a file
> indicates what the file really is, independent of its encoding. Read the
> HTTP spec some time. (Yes I know, not everyone is a web browser, don't
> try that argument, but its not just specifying web browsers).
I see no relavence whatsoever of the HTTP spec to our metadata spec since
our metadata spec is not based on HTTP. Our metadata spec does not, in
fact, have anything to do with the HTTP spec whatsoever.
I see no benefit to adding a ContentEncoding field which is not equally
satisfied by adding a ContentDecoding field. Additionally, a
ContentDecoding field allows for clients to optionally support it rather
than being required to.
> > 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.
> Thats a bad argument. If something is downloading an HTML file and doesnt
> intend to view it, then there's absolutely no problem with it thinking
> that its HTML.
Viewing is not the only thing contingent upon the associated MIME type of
a file being correct. Some clients might want to automatically guess a
reasonable filename and add an appropriate extension. This is a reasonable
feature even for command line clients and certainly a nice thing to have
for a Gnutella-style downloader client that lacks viewing capabilities but
allows for lots of simultaneous downloads.
Generally, my complaint is that an additional required field is being
added in order to support behaviour that should clearly be optional and
doesn't make sense for all reasonable clients. I'd prefer to have the
required fields be constrained to those that are necessary for any
reasonable client. Additionally, I find no relevance in what HTTP
considers to be standard headers, although it is a good source of ideas
for new optional headers that add value.
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
