[Moin-user] Changing default behavior on downloads.

[Thomas Waldmann]

> > Rendering of links to items should not depend on target mimetype (see
> > last post), the link by default links to a rendering of the item (how
> > exactly a item is rendered after you followed that link is of course
> > dependant on the mimetype of it, text/x-moin-wiki will be rendered as
> > usual, image/* might show some scaled view, application/zip might
> > display a listing of zip file directory, application/foo-bar might just
> > show some download button and some stuff from the metadata/history).
> 
> Ah, I see now. In which case, to me, it's still simple. For "data"
> (images, zip files, binary files, probably even program code -
> basically, anything other than text/x-moin-wiki, and equivalents for
> other markup), I want the "rendering" to simply be the item data, with
> its associated mimetype.

OK, now there are some new problems:

a) define "data" (then introduce magic dealing with it, then try to
manage the magic - see sorcerer's apprentice and how image links behaved
before 1.6 :)

b) There are some cases where different handling is possible, e.g. do
image/jpeg - you really want to see that 12Megapixel jpeg image (or
rather a scaled version)? text/python - show it highlighted (rendered),
show it raw, download it? Your browser might be able to help you with
the scaling (while other users' browsers might not be able to do that),
but it won't highlight python code for you.

UI: Where do we put the user interface for item operations (like delete,
revert, info, upload(!), download, different views of item, ...) if we
just feed the raw data after following a link to the item?

What do we show while the item is not yet uploaded? OK, we could show
the upload dialogue html. BUT: imagine that item is used with
transclusion, like {{/foo.png}} then it would transclude the upload html
- maybe not what you wanted). Note to self: transclusion needs more
thinking in general.

In short: if linking to raw, you can't do it the "object oriented
way" (having some UI like we have for wiki pages).

> The sort of rendering you suggest, I simply don't want. If, for a
> special case, I did, I would give the item a *different*, non-standard
> mimetype, and write an appropriate renderer.

Ehrm. You want to modify image/jpeg to image/x-jpeg-scaleto800x600 ???

Sorry, but that sounds like abuse of the mimetypes and you would have to
manually edit that (how? see UI problem...).

And even if one did that, you still have to UI problem. And if there is
no UI, there is no user decision / user interaction possible (one user
might want to see a scaled version, another might want to get the big
version). Right click in the browser is not enough to deal with that
problem for the general case.

> If Moin came with some
> such renderers bundled, that might help (but as I'd rarely, if ever,
> use them, I could equally see it as bloat).

Well, moin ever had that (called parsers) and they are quite useful
imho.

What we plan to do is just to generalize the concept and make the code
easier and more powerful (if you look into AttachFile, that is just one
big specialcase hack and a pain to maintain).

With the new storage and new UI you will be able to have a history of a
file, you will be able to revert user mistakes ("oops, i overwrote the
important.doc with a wrong version"), you can control access to files by
own ACLs, etc.

> If you have compelling examples of why a specific renderer might be
> more useful than straight download (note - the ones you mention above
> are not compelling to me) then I'd be interested, because frankly I
> cannot think of any.

There are MANY examples. Some you can see in moin wikis running since
years (by the use of either builtin or plugin parsers - they do nothing
else than special rendering of some piece of data):

 * highlighting of programming language files, of patches, ...
 * rendering CSV to tables
 * rendering Creole Wiki, ReST or docbook markup
 * rendering (safe) html
 * (see more on ParserMarket)
 * showing ZIP directories

Most of the above addresses the special case of text/* formats, but this
is simply because old moin storage code can not deal with generic items,
but just with (text) pages and attachments.

You see, it is not that easy to keep the old attachment link/download
behaviour.

In case we won't find a solution that makes everybody happy (AKA "the
wholy grail"), see it like this:
 * minus: the current plan will make item download 1 click harder to do
as it was in moin 1.5 and before
 * plus: you will be able to deal much better and safer with files
because of the new features

Ideas (thanks for getting me to think about this again :):

A) LINK BOX

Maybe the theme code can solve this dilemma by having a "Link box" that
has links for every link target used on that page:

     vvvvvvvvvvv link text, linked to rendering of target item
[DL] [OtherPage]
[DL] [/SubPage]
[DL] [/foo.doc]
^^^^ download/raw icon, linked to raw download of target item

Pro theme solution: if you don't like it, just use another theme.


B) Slightly modified inline link rendering

We currently decorate all non-intrawiki links with a link item (globe
icon for http links, disk icon for ftp links, terminal icon for ssh,
interwiki icon for interwiki links, etc.).

We do no use decoration for intra-wiki links, but we could:

               vvvvvvvvvv linked to rendering of target item
This is a [DL] [LinkText] example.
          ^^^^ download/raw icon, linked to raw download of target item

Problem: the decoration icons are currently rendered using css :before,
there is no html for them. If we re-introduce doing it by extra html (we
had that in old moins), it will cause some trouble to the gui editor
converter (could be solved by not doing it when feeding gui editor).,
maybe line wrapping problems (icon at end of line n, link at beginning
of line n+1), etc.

Problem: Not sure if that makes everybody happy, because of the icons
interrupting flow of reading and some people like to remove the icons
because of this.

Notes for A) and B):

 * it does not make too much sense if target is an item people usually
want to see rendered (wiki text, programming language text, maybe
images, ...). But we don't want to look at target mimetype, thus we
would have quite some icons with rather useless links.

 * minor problem: this won't easily work with interwiki links because we
don't know the target wiki software so we can't know the raw/dl URL.
That problem is a rather generic one and also true for non-ascii
interwiki pages and other stuff.