unsorted, uncondensed ideas and work notes for moin2

revs

about parent/child revs:

• parents are declared in the child

  • one PARENTID

  • TODO: multiple parents
• one head item will win (we should probably choose by mtime)
• merging/other heads will be a ui problem, store can ignore
• an item is: some revisions that share same itemuuid

storage

• some backends may have data that changes behind moin's back (e.g. the fileserver backend serves just some directory tree's content that likely is written to without using moin)
  • if we want to have realtime behaviour there, we never can use an index for that part of the namespace
  • if a refresh option is enough, we can just refresh the index on demand (for big changes, this can be slow)
• prefixes security.* user.*
• acls for metadata prefixes
• make user items more similar to non-user items:

  • user name -> item name (revision name to be more exact)

    • uniqueness of user names automatically given

  • change user name == rename item

  • delete user == delete item

  • user item data == homepage? -> NO, we'll have a separate userprofile namespace later.

  • own Navibar entries as subitem of the homepage
    • makes those easier to edit, sort, alias, adding descriptions
    • the subitem should be possible to show in the navibar of the theme e.g. optional sidebar
  • user profile dialogue becomes user item metadata editing
    • we need some better interface for metadata editing anyway, can use it for both user and non-user
  • user list is like page list in userprofiles: namespace
• make items more similar to those user items (see above)
  • have an email address - see emailimport feature
  • have a jid?

• multiple names are possible

  • usage as aliases

    • for items

    • for users

  • no redirect pages needed after rename (just keep old name in the name list)

  • reuse same content at multiple places (kind of hardlinked items)

• store revision data content under hash(revdata)
  • auto de-duplication
  • needs reference counting when nuking rev data, use index?
  • currently we use a (random, uuid4) DATAID, not the hash, so reusing would depend on some backend optimizer

acl

The ACL layer protecting the storage backends only protects storage (in old storage code), but quite some data is available via the index (and ALL data is in the index, including stuff that current user is not allowed to read).

So we need to think about how we handle ACLs. Revision ACLs are stored in index also, but hierarchic ACLs, configured before/default/after ACLs make this more complex.

Also we need to think about how much we are allowed to show from read-protected items:

• are we allowed to show the item name in index view / global/local history?
  • yes: quick, we do not need to check ACLs all the time, but we would show the "BigBoss/Fire Joe Doe" page name
  • no: more privacy/security, but we need to check ACLs for every item we list. but still, a user could discover such items accidentally if he tries to create a new item with this name or visits the item URL and gets "access denied".
• are we allowed to show metadata (editor, mtime, size, full history)
• we are not allowed to show data, of course (for historic revision data, the only question is which ACL shall be used: latest revision's ACL or THAT revision's ACL)

acls are faster now due to some intra-request caching.

getting rid of the pagename regexes

Currently (in moin2, similar as in 1.9), we have

    ('item_category_regex', ur'(?P<all>Category(?P<key>(?!Template)\S+))',
     'Item names exactly matching this regex are regarded as Wiki categories [Unicode]'),
    ('item_dict_regex', ur'(?P<all>(?P<key>\S+)Dict)',
     'Item names exactly matching this regex are regarded as items containing variable dictionary definitions [Unicode]'),
    ('item_group_regex', ur'(?P<all>(?P<key>\S+)Group)',
     'Item names exactly matching this regex are regarded as items containing group definitions [Unicode]'),
    ('item_template_regex', ur'(?P<all>(?P<key>\S+)Template)',
     'Item names exactly matching this regex are regarded as items containing templates for new items [Unicode]'),

What does it do?

• we need a way to know which categories (dicts, groups, templates) exist, thus the regex is used to filter the page names list
• category selection menu in editor
• filterCategoryPages
• fill category menu of adv. search
• extract categories for indexing

  • if we use tags in moin2 instead of categories, no extraction needed, we already have them separate in metadata

• wikidicts
• wikigroups
  • find group pages
  • in group members, find names which refer to other group pages (groups in groups)
• isGroupPage
  • do no allow users to choose a group name as their user name
• ACL processing to detect what's a group and what's a username?
• isTemplatePage
• find out what templates to show when creating an item

Issues:

• putting FooCategory on a page (moin 1.9) to categorize it is ugly (but no alternative, no metadata there)

• i18n issues "Category" might need translation for non-english users, thus the regex needs adapting
• even more complex regex if you want to support multiple languages
• similar i18n issues for template, group, dict pages

Idea:

• kill all those regexes
• with moin2 we can easily list all item names tagged with some tag

• instead of CategoryFoo we can just have a tag Foo (these tags would be "user tags")

• to mark group / dict / template defining items, we maybe can just tag them "group", "dict", "template" ("system tags")
• maybe have 2 sorts of tags: system and user tags, so the system tags (see above) don't show up in the user tag cloud

Issues with new idea:

• if we allow any item name for an item with a group definition
  • we can't know what's a username and what's a groupname by just looking at the name (but we could check if the name is in the list of groups)

    • We can also check that the username is a existing users name. That means we need to disallow to save a group with the name of a user. Or to create a user with the name of a group. May be that can only be solved by a namespace like prefix for the users name definition. e.g. User:FirstnameLastname.

      • yes, we could check user name list also
      • checking new user names against existing group names and new group names against existing user names avoid ambiguities
      • BUT, if some admin refers to not-yet-existing names in ACLs e.g. a group named "bosses" and forgets to create that group definition (or loses it somehow) and some user creates an account called "bosses", he'll get the ACL rights intended for the bosses group initially (same thing if a user renames himself to that name).

      • Same thing vice versa: an admin uses username "OurBoss" in some ACLs, but "OurBoss" did not yet create his account. Then 2 things could happen:

        • some other use create "OurBoss" user account (that problem is not new and it is a mistake to refer to non-existing accounts in ACLs)

        • some other user create a group definition "OurBoss" on a wiki page and adds some people in that group (that'ld new due to overlapping group and user name space)

      • User: prefix is not compatible with the ACLs we get with 1.9 data

      • User: prefix is also a lot to type in ACLs with multiple user names

  • we can't disallow "group-like names" because there is no pattern
    • Using Usernames only with a namespace prefix would solve that too
• any other issues with this idea?

Bug or feature:

• if one defines a group with the same name as a user, this would make group members equivalent to the user (think of "very good friends", representatives, substitutes)

• only the "owner" (<name>) of the <name> item should be able to add the <name> group metadata to the item, otherwise someone else could get his acl privileges

xml

xmlrpc / json

after storage api has stabilized, create xmlrpc adapter:

• that sits on top of storage (== on router backend)
• that uses normal auth chain
• api corresponding to storage api
• use existing xml serialization?

• makes xmlrpc storage backend possible: wiki ui > xmlrpc storage backend ---> xmlrpc adapter > storage

Maybe we want json rather than xmlrpc?

new browser features

web storage

good support on modern browsers, can locally store up to 5mb, easy to use.

• store editor content every x seconds
• trail?

forms

• autofocus
• placeholder
• required
• url types
• email types

How to integrate attrs with flatland?