> 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 mail. 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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Moin-user mailing list Moin-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/moin-user
