Ideas and scribbles regarding the Interface specifications for my SOC proposal.
Interface between Moin and Storage Engine
se
- Storage Engine Module
- Access to the storage engine should be through methods of a proxy/delegator design pattern, hiding the structure and implementation behind. This allows future modifications to the engine without significant amount of changes to the code, the only changes would be in the proxy interface.
Page Data Related
itemname - Unicode item name (if we get a string, auto-decode to unicode using config.charset).
rev - Revision Number. If revision is zero, refers to latest version. Should the value be out of bounds get latest or throw exception.
index - Refers to a position within a list of data for an item. May not be needed if we handle sections by contained item objects. However, isnt this how subpages would be stored and not sections within a given page? Would sections require different metadata? Could they share a single set of metadata? This would allow semaphore locking at a section level instead of page.
- caching is handled transparently by storage engine (no caching in first impl.)
se.add_page_data("WikiName", Data)
Adds data into itemname, placing it numerically at the end. Possibly have sorting flag (A-z, chronologically etc.) for automatic sorting on insert (well, commit) and re-ordering capabilities.
se.get_item_data(itemname, rev=0, index=0)
Gets data for a certain itemname.
se.set_item_data(itemname, data, rev=0, index=0)
Sets data for a certain itemname.
se.del_item_data(itemname, index=-1)
Deletes a piece of item data at position index in the list. Default's to last on the list (-1).
- Prehaps we could make revision numbers start from 0 and make -1 latest version for consistency? Adaptor would be able to sort that for existing code.
se.clear_item_data("WikiName")
Removes all data from an item (delete all).
Page MetaData Related
Use dict-access, not functions?
- I wouldn't recommend this as its placing a form of data structure that might be changed in the future on the outside of the interface. In reality all it would do is forward onto a dictionary, do you feel that strongly against it?
see wikiutil.MetaDict, don't you think that can be done in a similar way for every backend? just using item.meta['rev'] += 1 is much easier than se.set_item_meta(item.name, "rev", se.get_item_meta(item.name, "rev") + 1).
se.get_item_meta(itemname, "MetaDataTag")
se.set_item_meta(itemname, "MetaDataTag", MetaData)
se.clear_page_metadata("WikiName")
- Maybe setting to None can do this
Wouldn't clear all, would just null out that particular piece of metadata.
Page ACL Related
Would ACL Objects be add/del like page data or just set-able?
se.get_item_acl(itemname)
se.set_item_acl(itemname)
se.clear_item_acl(itemname)
- Maybe setting to None can do this
Wouldn't clear all, would just null out that particular acl.
- ? if an acl is set to None (or ""), there is nothing left
Check if we need this at all. ACLs are metadata.
Page Information Related
se.get_item_revision(itemname)
![/!\](/moin_static194/modernized/img/alert.png "/!\")
explain
se.get_item_parent(itemname)
- Explain function
I was hoping you would http://arch.thinkmo.de/moin/epydoc/public/MoinMoin.Page.Page-class.html#getParentPage :).
- this has nothing to do with storage, this is just an operation on the item name
- Isnt the whole point of the abstract storage engine layer to formalise how data is handled in the engine. Thus wouldnt this be in there?
- this has nothing to do with storage, this is just an operation on the item name
Page Editing Related
We already have locking functions, see lock.py
- Already know about it :). Wouldn't locking move into Storage Engine area, mainly because SVN backend would have its own handling (or handle differently)?
se.get_item_lock(itemname)
se.clear_item_lock(itemname)
This looks like a very simplified view on locks ... check out the current lock API and don't forget that page editing involves three locking levels currently which work completly different each. -- AlexanderSchremmer 2006-05-27 23:15:10
Engine Manager Related
The storage implementation access (open/close) would be transparent to this interface, and would be initiated by the storage engine if a request comes in.
se.manager.check_connectivity()
- Performs a diagnosis on the connectivity to the storage implementation.
se.manager.set_storage_location(uri_to_subversion_host)
- Sets the storage engine location.
se.manager.get_page_count()
Interface between Storage Implementation and Storage Engine
- si.open_storage()
- si.close_storage()
- si.fetch_item_data(itemname, rev=0)
- si.fetch_item_meta(itemname, rev=0)
Some stuff is missing here:
- methods to put item data / metadata
- we need methods for that, its more pythonic I thought to just access the properties :).
- method to remove item revisions
- a method to list items available (either "existing" items only or including "deleted" items)
maybe have some filtering capability in that listing method (for TitleIndex, Searching, etc.):
- only specific mimetypes (e.g. text/*)
- readable by some user (ACLs)
- which stuff is done on which layer has to be checked.
Abstraction Engine Classes
Item(MetaData, Data)
- Page
- User
- ACL
- Data