[Moin-user] Changing default behavior on downloads.
tw-public at gmx.de
Wed Oct 1 04:39:04 EDT 2008
> Really, all I want is a sane method of making files easily
> downloadable. :-)
I completely agree on that. :)
But that's not all I want to do, I want also that they can be dealt with
in a consistent way as with all other (page) items: rename, delete,
revert, acls, etc. - and this needs an UI and a link to raw-only can't
give an UI obviously.
Also, doing 2 clicks is not "not easy", it is just one click more - for
a good reason.
When thinking about each time I downloaded some windows sw from the
internet, I often had to do 4 or 5 clicks for no good reason (just that
they get more ad impressions :). Don't get me wrong, I think THAT sucks,
but what I want to tell is that (windows) users are familiar with doing
some clicks to get a download.
> That's why I suggested in my earlier email if I
> could just change the "&do=view" parameter, it would quiet my users
> for a little while at least (future be damned, LOL!).
I am thinking about this for 1.8, but you have been warned about problem
coming back in 2.0 or so. So that setting (if implemented) would be kind
of unsupported and deprecated from the start.
> I know that a wiki presents it's own unique challenges, by the nature
> of what it does. But, there has to be *some* happy medium. Imagine
> if the rest of the web operated this way? Remember back before admins
> figured out how to configure mime types, and you would occasionally
> click a download, and instead of downloading it dumped a bunch of
> binary onto your screen (and usually crashing the browser in the
> process)? I feel sorta like we've taken a step back to those days
> with the convoluted way attachments are handled here.
I am still waiting for good suggestions about how to handle it.
I outlined some fundamental problems in my last mails, but except my own
"link box" and "double inline link" suggestions I did not see anything
how we could handle items in future other than we already plan to do.
> It seems to me that if a web server can have a mime-types table, that
> the wiki can have a similar approach. I agree with Tim that it seems
> this mimetype handling is best left up to the browser/server, not the
> wiki (but, yes, I've read your other posts and know that it's not as
> simple as that. :-( ).
See my other mail and note that the fundamental problem we have with
"attachment links to raw" is not a mimetype issue.
We will have the mimetype in metadata, but we will have a performance
issue if we have to open each target item's metadata just to implement
some magic for creating different links depending on mimetype. Using
just the "filename extension" is problematic as I have shown in my last
Even if we ignore the performance problem, the problem of "where do we
place the item user interface when linking to raw" issue persists. So
how do you revert the last upload of foo.doc if you just have a raw link
to it immediately triggering a download? How do you rename it?
Also, please be aware that magic is often strange to the users. Having
learned that, I usually try to do stuff non-magic because if stuff
behaves consistent and always in the same way (following some easy
rule), that is also a quality in itself.
If something behaves magic (and sometimes in a way the user did not want
or can not explain), that can be an annoyance in itself (try to create a
link to an image in moin 1.5 to see what I mean) and the means to "work
around" that usually make things even more complicated.
Maybe I wasn't too clear about that there won't be something like the
AttachFile action called from the "attachment containing page", because
files will be separate items (and not contained within a page). So the
only relationship will be "is a sub-item" (item foo is text/x-moin-wiki,
item foo/bar.txt is text/plain, item foo/baz.doc is app/mwsword, foo/xxx
can be image/jpeg :) and that relationship will be established by the
item name (as for pages and subpages).
> You mentioned
> you're against any "magic" on Moin's behalf, but simply defaulting to
> "view" is a little *too* simplistic. Even if it was based on crude
> file extensions (.doc, for example), that seems better than nothing.
OK, assuming that I put an item called graphviz.dot into the wiki, how
would it work?
Assuming I put MyProject/Makefile into the wiki, how would it work?
> Honestly, I'm not sure the Wikipedia-style approach is the best method
> (a flat file structure). It seems to me that that style would make
> revisioning in future versions more difficult. Also, I think that if
> you had it in a flat structure, it would be harder to manage
> individual file protection via most authentication methods or ACL's.
But it makes uploading php exploits much easier, if stuff is directly
served by apache. :P
More information about the Moin-user