Christopher Denter

Contact

About me

Hi. My name is Christopher Denter. See this link for a summary of my activities. I'm participating in GSoC 2009 for MoinMoin. Click here for more information on that.

My schedule (besides GSoC)

This marks dates where I won't be available due to other liabilities (I'm still a regular person/student as well :) ).

Important dates (not listing time for preparation for exams and the like):

Since I'll be quite busy with preparations for exams here's some days where I hope I'll have some time to work on Moin (no promise):

(I'll of course try to code whenever possible in between)

Thoughts on attachments (Johannes)

Status quo
attachments are per-page
Goal
attachments are just regular "items" like pages, with different mime types

This table lists existing attachment operations and their replacement:

Attachment operation

after storage refactoring

view attachment

view item

download attachment

download raw item

view attachments to a page

view list of sub-pages of a page (including mime-type)
show different links (view, download, raw, ...)

upload attachment

upload raw item when "creating page"

delete attachment

delete the item

include image attachment: {{attachment:foo.png}}

{{/foo.png}}, old syntax still accepted

include attachment "from another page": N/A

{{otherpage/foo.png}}

rename attachment

rename the item

unzip attachment abc.zip

unzip item abc.zip (offered in zip file view), put contents into {extracted sister items}

install attachment package.zip

install the item (offered in zip file view)

file attachment browser

??

(!) The old attachment: syntax should be killed and a converter should convert the markup (basically it is about replacing "attachment:" by "/"). -- ThomasWaldmann 2008-05-27 15:43:47

Notes

  1. remove unnecessary cross-accesses of internal object attributes (not very important but would be good before writing many backends)
    • item.rename() can update item._name when the rename succeeds instead of the backend doing so
    • _commit_item can be passed the new revision object instead of having to pull it out of item._uncommitted_revision, item._uncommitted_revision can be set to None by Item.commit/Item.rollback after those actions have succeeded
    • revision._metadata need not be accessed by the memory backend, it can leave it at None, wait for _get_revision_metadata to be invoked and then store the dict into a different attribute
    the result of this is that revision and item object internals need not be accessed even by the backend, and that those attributes the backend does access it has put there itself.


wiki-wide metadata/changelog

(Johannes)

Currently, renames and item creations are not logged anywhere, and thus, do not show up on RecentChanges. To fix this, I propose to add a new API call:

which iterates the "item log" containing information about when a specific item was created/renamed (and from what to what). This information would be folded into the news() iterator as well, which already just provides similar information about revisions.

For wiki-wide metadata, one could allow accessing the backend as backend['meta'], with update/publish semantics like item metadata.


CategoryHomepage

MoinMoin: ChristopherDenter (last edited 2010-02-10 12:23:41 by PawelPacana)