Really, all I want is a sane method of making files easily downloadable. :-) (actually, I just want my users to leave me alone about it, but we need to fix the first part before the second part will happen. :-) 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 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. 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. :-( ). Like what Paul said, with the exception of graphic files, and maybe some embedded media files, I want *everything else* downloaded. That includes zip files. For most users, it's not useful to display the contents of a zip file, they want it downloaded to their computer. Don't get us wrong, we know that you're laying the groundwork for some important bold new features (revisioned attachments, nice! <drool>), but we have to also respect the behavior users expect (otherwise they come yelling at us!). 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. At Tim Bird— 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. Just my two-cents. :-) I appreciate the dialog this thread has generated... -Rick On Tue, Sep 30, 2008 at 2:01 PM, Tim Bird <[EMAIL PROTECTED]> wrote: > Thomas Waldmann wrote: >>> Maybe there should be *three* options - ?render=raw, ?render=manager >>> and ?render=formatted, >> >> Ugh, that would make linking even more complicated than it already is. >> |-) >> >>> with the default varying by mime type, >> >> As I said, if link generation depends on target mimetype, it might get >> very slow as there can be many links on a page... > > At the risk of pouring more fuel on the fire, I think the > basic problem is in having MoinMoin manage the presentation to > the browser of the "raw" attachments at all. > > The reason for all the weird behavior is simply that MoinMoin > is trying to do some portion of the work (e.g. mime-typing) > that the web server and/or browser normally do, and messing > it up. A case in point is that when I try to do "save-as" > by right clicking from my browser, my browser uses the page > name, instead of the name of the attached file (because that's > buried in the params in the URL, instead of in the path where > most browsers expect the downloaded file name to be). This > 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". > > 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). At least for the current > version of some item. This allows the web server and browser > to handle regular download of the items in the standard > fashion. If MoinMoin wants to build a fancy page for handling > meta-info (history, revisions, comments, etc.), it can do that > through a link through itself. > > That is, the "raw" url for some item should not be: > http://server.com/moin.cgi/PageName?<some weird args here>?item=foo.pdf > but just: > http://server.com/really/just/a/file/path/foo.pdf > > The big problem, of course, is that the file space is segmented > by page name. If the attached files were in one directory, this > becomes trivial to implement (at the cost of possible name > space collisions - although I'll note here that even wikipedia, > with it's enormous size, uses a flat uploaded file namespace). > Even if you present the documents under page names, > then you could still put them out somewhere where the web server > can serve them directly, instead of having MoinMoin get in the way. > -- Tim > > ============================= > Tim Bird > Architecture Group Chair, CE Linux Forum > Senior Staff Engineer, Sony Corporation of America > ============================= > > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
