[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