|Syntactic Confectionery Delight|
Re^2: Multiple scratchpads - one public, one private (personal wiki)by tye (Sage)
|on Jun 09, 2004 at 17:37 UTC||Need Help??|
I think we should change the wiki edit page to only allow janitors and owners (not writers) to be able to change wiki titles. We need to fix the canUpdateNode() and canReadNode() to special-case wikis so we can use them several places (and so regular displaytype=edit can work on wikis). Once that is done, I think we could do the following...
At ysth's suggestion, I could go for allowing members of a certain level to create a *single* wiki that they could change the title of and set the permissions on (you are limited to setting a minimum level or picking an existing group -- though if people start making requests for new groups to be added, I'm going to delete their wikis). The node=tye;type=user;displaytype=xml would report the node ID of my wiki if I had one like it will soon do for scratchpads. Super search would allow you to search wiki's by content, title, owner, just like it does for other nodes (we'll need to have it post-process the list and not list nodes that you don't have access to read, a simple change).
And, of course, gods can create wikis with a specific title and permissions if given a good reason to.
We'd want a superdoc that lists wikis sorted most-recently-updated first (create a bookmark that feeds it a specific list of wiki IDs if you only want to check for updates to certain wikis).
If your wiki gets wiped out (or otherwise ruined), then you can use "edit history" to see who changed it when and how and cut'n'paste removed parts back into existance (which should be a good reason for people to not bother wiping wikis). This "history" link needs to become public (in the "title chooser", where "print" and "xml" links are, preferably only if there are history records to see), not just in the janitors' nodelet. But we need to limit who can see the contents of edit records to not include those who can't see the node that was editted and to limit it somewhat for fully public nodes1.
You wouldn't be allowed to delete your wiki, but you could empty it and set the permissions so noone else can edit it. This is just so wiki node IDs don't scroll up and up when people can't decide whether they want a wiki or not.
The space required for wiki edit history could become rather huge, which is one reason why only one wiki per person and only after you reach a certain level. pmdev implementing "preview" for wikis could help a lot with that. A purge process will eventually be needed either way (and I believe in lots of history, so I wouldn't purge records less than 1 year old).
If your wiki becomes a great success, then it could be adopted by the gods (which would make its title and permissions somewhat set in stone) so that you could create a new personal wiki.
1 Some appear to not want the public to be able to see edit history of nodes (every edit to a wiki is recorded; for other node types, only edits done by janitors are recorded). I guess one point is to prevent robots from finding e-mail addresses that were removed when someone realized the spam risk. I'm not sure we should prevent the public from seeing edit history, but perhaps just restricting it the registered users would be enough? That prevents anonymous monks from seeing how a node change which they certainly may have valid reason to do, but I don't feel too sorry for them if they have to register for that access even if they feel that they never want to post via that account.