[Moin-user] Changing default behavior on downloads.

[Tim Bird]

Thomas Waldmann wrote:
> A browser that is using the filename to determine the mimetype of a file
> it accesses by http is doing it very wrong, because it rather should use
> the mimetype given in the http headers.
Agreed.

> 
> Using the extension of the file is OK if you don't have any doable
> better way, but if a http header tells the browser that "this is
> text/x-graphviz-dot" (I am making this up), then it should not throw
> that away and look at its .dot file extension and decide "oh, that is
> application/msword!". So, if you see such behaviour, file a bug against
> the browser. :)

I don't know of any browser that does this.  I don't think I
said I did.  The _specific_ complaint I mentioned was with the name.
And when I talked about mime types, I referred to the browser/web server
combination.

> Moin currently has no way to store additional metadata for attachments
> (this will change in the future), so what moin currently does IS to look
> at the filename extension and send that mimetype (this is basically the
> same what apache does with its mimetype mappings).

Which duplicates web server functionality, and practically guarantees
incongruity between Moin and the web server for some users at some point.

> We have extended the extension -> mimetype mapping table for some cases
> that were missing, so it behaves better than when just using python
> stdlib.
> 
> In future, items will just have mimetype stored as metadata and we will
> just send that (when accessing the raw item data).
OK, but see above.  It sounds like a lot of unnecessary work.
The bulk of the web functions pretty well delivering
files to users without having to store per-file meta-data.

>> is annoying as all get-out.  Instead of trying to manage
>> the mime-typing, MoinMoin could just use standard URLs,
>> and let the server and browser "do their thing".
> 
> If files are handled by moin, the server is not involved at all, moin
> emits the complete http response. See below for the other case.

Yes, I believe that's my point.  That's the problem.
Moin currently doesn't do as good a job as the web server of
handing back the mime type.  Preserving Moin's layer of mime type
handling makes it likely that there will be incongruities in mime
type handling in the future.

If your main argument for doing this is for standalone
configurations MoinMoin, then it makes sense that you'd
duplicate this web server functionality.  But it would be
nice if people with fully functional web servers didn't have to
suffer for it.

>> IMHO, it would be nice if non-page items (e.g. files) were
>> accessible from the the web server via direct links
>> (NOT via the MoinMoin CGI script).
> 
> That was removed quite a while ago (with good reasons I won't repeat
> here) after being deprecated for years. It sucked and it won't come
> back.

I suppose I'll take your word for the good reasons.
But it's hard (now) to evaluate what sucks more, that system
or the one we have now.  I used the old system (I've been a Moin
user since before 1.0), and it worked well for my needs.
I suspect it was a victim of a long-term vision of internal
code organization that has not yet come to fruition.  But
from an end-user usability standpoint, it was, IMHO, superior
to what we have now.

Now, having said all that, please understand that I appreciate
the enormous effort that has gone into Moin, and I continue
to use it for a number of projects.  Please don't take my
nitpicking on this issue to be indicative of ingratitude to
Jürgen, you and others who have made Moin such a great system.

Thanks,
 -- Tim


=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================