[Moin-user] Changing default behavior on downloads.

Rick Vanderveer rick.vanderveer at gmail.com
Tue Sep 30 16:01:54 EDT 2008


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 <tim.bird at am.sony.com> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/moin-user
>




More information about the Moin-user mailing list