Unify pages and attachments to mimetype items

For discussion please use the discussion subpage and comment there. Please be constructive and make better suggestions about how to do it.

Currently (and likely up to moin 1.9), pages and attachments are handled very differently. If we store a MimeType for items we store, we could unify storage of page files, user account files and uploaded files.

Work on this kind of storage was done in SOC 2008.

Terminology

For a better understanding, let's use this terminology:

mimetype text/x-moin-wiki

content of the kind of markup you usually use with moin (aka #format wiki)

raw

like in "raw action", "raw content", "raw url" is related to verbatim file content as stored by the wiki storage backend

• for a usual wiki page, this is the text you see in the text editor, type text/x-moin-wiki
• for a pdf file, this would be direct "binary" content of type application/pdf (like stored in .pdf files)
• there is no theme output / no user interface at the raw url, just http headers + raw content

render

like in "render an item", "rendered view", "render url". "render/show action" means to show the wiki user interface frame (generated by the theme) and some kind of display of the item in the content area.

• For mimetypes we have code for showing them in a browser you likely will see the item data on screen (a rendered wiki page, a rendered (scaled) image, a rendered highlighted piece of code).
• For mimetypes we don't have such code, you will likely see just some metadata and maybe some buttons for upload/download.

highlight

for some text/* mimetypes like programming source code, diffs, irc logs, etc. we can use a highlighting renderer - this could be the fallback of the (non-highlighting) rendering for cases we can't render in another way than highlighting.

item

generic datatype that is able to store revisioned metadata and data - there are no pages and no attachments any more, just items. The mimetype metadata tells what it is.

Features

• Revisions for uploaded files (same code as for wiki pages)
• Reverts for uploaded files ("")
• Deleting a file is same as deleting a page (same code, both are items).
• Upload/download file is same as upload/download of wiki page text (like files, wiki pages can be uploaded/downloaded then).

  • The MissingPage stuff must be extended to offer upload with mimetype (for uploading files or wiki pages).

• action AttachFile will be removed, moving those functions to the core code

  • check twikidraw interface and either keep that or find someone changing twikidraw maybe?
• will make global and "local" files possible (like main pages and sub pages)
• linking files will be easier (same linking code for all items, same as linking to wiki pages)
• showing files inline could be done, if they have a renderer (trivial for std. images, doable for LaTeX etc.)

• derive "parser" to be used from MimeType (wiki, rst, images, LaTeX)

• encoding- and whitespace problems resolved by same code as for page titles
• ACLs for files
• clean handling and storing of MIME type
• purge policy could be implemented (with defaults for each mime-type), e.g. purge revs older than a week except for the last n revs
• maybe hard deletion action ("nuke rev", "nuke object") with some special acl right
• maybe limit max file size
• when going to URL of an item, some kind of "rendering" happens (note that this does NOT necessarily mean that the data content of the item is shown on screen)
• Less code. Remove crappy code.
• Easier markup.

Linking

• a link to any item will be easily possible by using [[target]] syntax (or [[/target]] for sub-items)

• linking will use the default "show" action as target URL (as it is the default action, it is not specified)
• the semantics of "show" is to give some rendered representation within the content area of the theme:
  • for text/x-moin-wiki this will be parsing by the wiki parser, emitting html (as usual)
  • same for other text/* types (creole, rst, ...) supported by some parser

  • text/<programming language>: render the code in a hightlighted listing

  • for text/*: render the text data in a pre section
  • image/*: render a scaled preview of the image and also give some metadata about it (e.g. EXIF data and user-provided metadata below or right of image)

  • more renderers can be added as plugin (for some stuff, we could just use <object> element to have the client do something meaningful with it)

  • default fallback handler for */*:
    • just showing some metadata and user interface for up/download, history, rename, delete, etc.

Transclusion

• a transclusion of an item will be easily possible by using {{target}} syntax (or {{/target}} for sub-items)

• the semantics of transclusion is to show the item at the place where the transclusion markup is encountered
  • for some mimetypes, transclusion could be handled by the server (e.g. for text/* types, the server could render the target and include it in the output on the server-side)
  • for some other mimetypes, transclusion could be handled by the client (e.g. for images and multimedia files)

    • <img src=".../target?action=raw"

    • <object data=".../target?action=raw"

    • raw action will just send the http headers (content-type/length/status) and the item raw content

• for non-existing transclusion targets, we need to link to show URL to get the UI for uploading it

Download

... will be offered by links in the theme (on the page shown by "show" action) and trigger download of currently shown item revision.

For download there could be 2 links:

• content-disposition: attachment
• content-disposition: inline
• action=raw means which of those? use dispo=(attachment|inline) param?

Upload

... will be offered by a link in the theme (on the page shown by "show" action).

It will show a form with those fields:

• filename selection
• mimetype (if not give, we will try to autodetect it from file extension)
• upload comment
• UPLOAD button POSTing the form to ...?action=upload

A upload will create a new item revision, of course.

Edit

... will be offered by a link in the theme (on the page shown by "show" action) for any mimetype we can support with a online editor (text/*, twikidraw, others?).

Editor could maybe just POST to ?action=upload to save the result.

GUI editor needs specialcasing as the converter needs to get called. Additional convertfrom=text/html convertto=text/wiki parameters to upload?