Implementation Links    (1ZO)

Use Cases    (SB)

Wiki Snapshot    (SC)

View the entire Wiki as it looked on a certain date and time. Similar in concept to the WaybackMachine.    (SD)

Multiple Titles Per Page    (SE)

Allow multiple WikiWords to point to the same page. This implies using meaningless identifiers to name pages rather than the WikiWords themselves. Read the Collab:HomePage thread on this subject or vanzari auto.    (SF)

Node Querying and Versioning    (SE)

The API should support querying of nodes, not just pages.    (SH)

Remove Subpages Support    (SE)

See RemoveSubPageFeature. Removing this feature doesn't mean that pages with slashes are disallowed; it just means that those pages are stored in a flat namespace, the same as any other.    (SJ)

Note that one direction we do want to support is multiple databases within a single Wiki process. This would in a sense give you at least one level of hierarchical namespace.    (SK)

Multiple Character Sets    (SE)

Necessary for proper i18n.    (T6)

Search    (SE)

Resource    (7V0)

Belford Lawsuit | Belford Lawsuit | Belford Lawsuit    (7V1)

Text search of content. For starters, it can just be a straightforward string search, perhaps case insensitive.    (SS)

There should be some semantic connection between the way that namespaces relate in terms of searching for pages by name withing several "sub-wiki", and the domains for search. I.e. I can search one Wiki or groups of Wikis at different levels of granularity based on name-space hierarchies.    (TY)

[Belford Lawsuit] -- [Belford Lawsuit] - [Belford Lawsuit]    (7V2)

Access Control Permissions    (SE)

Must support access control. For example, when doing a recentChanges query, it should only return pages that the user is allowed to access.    (TF)

Ideally, the permissions should be node-granular. This would enable scenarios such as follows: BlueOxenAssociates has amassed quite a bit of information regarding the tools it uses internally. I'd love to make those pages public, but those pages have information about our internal configuration that I would like to keep private. With granular permissions, I could make those chunks of the page private and the rest public. When authorized people viewed the page, they'd see all the content; everybody else would only see the public portions.    (TG)

I think this is a lovely idea, and can even imagine the use of the permission being relatively straightforward. But the user interface for setting the permissions makes me pause. --ChrisDent    (TI)

Yup, this is a problem, but not just for granular access. It's also a challenge for granting permissions on a page level. MoinMoin does this by adding pragmas on a Wiki page; not a great solution, in my opinion, but doesn't require any UI changes either. Either way, from the perspective of the DataBase spec, I think it's worth building this capability from the start, even if it's not immediately implemented in the UI. Our nodes will already support metadata, and permissions are just another type of metadata. --EugeneEricKim    (VN)

Administration of the permission models is the difficult thing from a use standpoint. Developing good use cases around these functions is critical. Ideally this builds off the information hierarchies present in the data, node hierarchies within pages, and name space hierarchies between Wikis on the same sight. The Who side of this should be structured as well (as in Who gets access to What, and that Whos are grouped into roles and typically a permission to access is given to a role or roles rather than individuals). --GerryGleason    (TZ)

Design Discussion    (SE)

Data Structure (What Is A Page?)    (SE)

We need to think/discuss what our fundamental object models are. Is a node or a page the basic atom of the system? If it's a node, then is a page just a list of nodes (purple number references), or is it also a node in a hierachy of nodes?    (SL)

There needs to be separate notions of nodes and pages, the node being the most granular atom in the system. A page is not simply a node. A page is a graph of nodes. It also has its own metadata -- for example, page labels.    (T7)

Are nodes hierachical? In other words would it make sense for the purple number of the document level node to represent the document?    (SN)

This is a loaded question. First, a terminology gripe. A purple number is not a NID; it is a UI element, a visual instantiation of a NID. Right now, we're not assigning all nodes NIDs, so in fact only nodes with NIDs get PurpleNumbers. That may (and probably should) change.    (T8)

Yes, should change --ChrisDent    (TJ)

Ok, but clearly they are closely tied together. I presume that APIs will often use NIDS to implement functions that implement purple number based features. As UI elements, purple numbers are more than just link targets, right? In a transclussion, does specifying a node include just the node itself, or can it also refer to the entire tree below it in the document graph as well? --GerryGleason    (U0)

At the moment a transclusion only includes the identified node. Part of the reason for wanting nids on everything is to investigate transcluding entire trees. Or to put it another way: it would be cool to be able to transclude subtrees, and having nids on everything seems to walk with that. --ChrisDent    (VL)

If a node gets and purple number, but not an NID, then how do you keep the link constant?    (U1)

If a node has a NID that is displayed, the NID is displayed as a PurpleNumber?. --EugeneEricKim    (VO)

Second, whether or not pages are hierarchical or are more general graphs depends on how we want to implement them. The key is TransClusions?. Is a TransClusion simply a link (or "path," in NODAL terminology) to an already existing node, or is it a new node (with its own NID) that refers to the transcluded node. Right now, we're implementing it as the latter, so pages are indeed hierarchies.    (T9)

Can you explain a bit more how a link style TransClusion system would not be a hiearchy, I'm not getting it. --ChrisDent    (TK)

I'm not sure either. By "new node", do you mean that you copy the contents of the transcluded node or nodes into the referring page but leave a record of where you got it (so you could update it later, for example). Can you now separately modify the transcluded content? --GerryGleason    (U2)

I'll answer both questions at once. Suppose you have you have two docs. The first doc has three unique nodes -- 1, 2, and 3. The second doc also has three unique nodes -- A, B, and C. Now suppose the first doc consists of its three nodes and the last paragraph is a transclusion of node B from the second doc. Suppose that the second doc is the three unique nodes and the last paragraph is a transclusion of node 3 from the first doc. You get the following:    (VP)

  1    A
  |    |
  2 +->B
  | |  |
  3-+  C
  |    |
  +<---+    (VQ)

This is a non-hierarchical graph. You resolve this one of two ways. You either define a document as paths to nodes (i.e. the NODAL approach), or you create new reference nodes for transclusions (which is essentially what we do now). Reference nodes are not copies; they're pointers, so you can't edit them directly. Here's how the docs look with reference nodes:    (VR)

  1    A
  |    |
  2    B
  |    |
  3    C
  |    |
  4(C) D(3)    (VS)

Now everything is a hierarchy. --EugeneEricKim    (VT)

To answer the meat of your question, if we were to assign NIDs to all nodes, then the NID of the document node could indeed be the identifier for the document.    (TA)

This opens up the possibility of doing one or both of the following:    (TL)

I like these conceptually, but am still wondering about the implications. Then parts of pages could be given names and aliases of their own, but would these be more like purple references where the link puts you at an anchor of a larger page or would you format the sub-page node as a page without the rest of the document? --GerryGleason    (U3)

API    (SE)

Moving details of this here: DatabaseAPI    (WC)

MatthewOConnor? started abstracting the old PurpleWiki database calls into a higher-level API    (WD)

Plugin Architecture    (SE)

Multiple databases are multiple Wiki configuration potentially all sharing the same mod_perl thread (or pool of threads). Potentially, each of these could be running a different set of plugins supporting different sets of features (i.e. differing parser/view pairs for different wiki syntaxes, and much more).    (SO)

That's the process half of this, but more important to the users will be the ability to mix and merge namespaces. The gets into LinkSemantics?, which we should expand on separately.    (SP)

ChrisDent described some elements of how a backend plugin architecture might look.    (TE)

Chris' discussion in the above linked email is excellent. Please include substantial parts of it in this and other Wiki pages.    (U5)

Name Spaces, or Content Groupings    (SE)

Naming needs to be taken on separately, particularly as in rests upon LinkSemantics?. We need to be explicite about the lifecycle of objects and their dependence on an underlying data infrastructure and the naming systems that attempt to glue it all together. I think we should err on the side of making classes of similar identifies more equivalent (i.e. normalize case and remove non alphanumeric, although the rest may be retained for viewing). Aliases could be another layer on this normalization.    (SM)

Other    (SE)

Should there be such a thing as a "minor edit"?    (ST)

Can we get away with using timestamps as version numbers, or do we need an additional numbering scheme?    (SU)

I'm a fan of using timestamps. The only problem i can think of with that is there is a possibility of needing subsecond versioning (in the case of wiki pages that are machine updated). If we do that, the timestamps take up a fair amount of real estate and some datastore implementations might not deal with sub-seconds without help. --ChrisDent    (TQ)

History    (5Z)

August 11, 2004    (SQ)
ChrisDent noodles a vision of database doings.    (SR)
January 30, 2003    (60)
ChrisDent's notes on the UseModWiki Database classes    (61)