[tahoe-dev] File types and encodings

Brian Warner warner at lothar.com
Sun Mar 14 15:50:07 PDT 2010


Jeremy Fitzhardinge wrote:
> 
> As a fallback, using a heuristic table to derive the type is useful for 
> well-known types, but defaulting to text/plain if that fails seems 
> pretty odd.  Why not default to application/octet-stream?  A 200MB .m4v 
> file is definitely not text, and anything trying to treat it as such 
> will get a shock.

Actually, it was so that the ".py" files that I wanted to pass around
would be displayed in the browser, not mapped to some unhelpful opaque
download-and-save-only "application/x-python" nonsense. Same for a lot
of other common extensions used on files that are basically just text.
I'll admit that this choice was mainly driven by my personal preference
and habits.. if I used more .m4v files I might have gone a different way.

A content-type/content-encoding tag seems like a good idea. We could
define a new immutable filecap type ("typed-data" instead of just raw
data?) which puts a slot in the datastream for this information. Or, as
David-Sarah pointed out, we could probably just add it to the UEB and
older clients would just ignore it.

cheers,
 -Brian



More information about the tahoe-dev mailing list