NEWS
Contents |
Nemo's Enhanced Wiki System
(as named by Screwtape - in accordance with NINS)
aka
- Never Ending Wiki Silliness *
In summary
NEWS is Nemo's idea that his next generation personal website (version6) should be an integration of the various aspects of his current website. The basic idea of NEWS is:
- A Wiki editing and linking system. This promotes easy editing and interlinking
- A user-based permissions system. With an effective permissions setup, we have a Content Management System (CMS) using wikitype editing as it's backend.
Everything else is built up as special pages within the NEWS. eg...
- Image/File gallery - pages devoted to handling an image. May occur anywhere within the NEWS site.
- Chronological Journal (aka: "Blog") - pages devoted to a specific date, rather than a specific topic. Again, these may occur anywhere within NEWS, allowing for nicer integration of topical date entries.
So, how are these parts all integrated under a wiki?
- NEWS/TextFormatting - Discussion of possible markup ideas
- NEWS/Markup - The actual markup
- NEWS/Implementation - Details of what needs coding (and how?)
Some detail
The idea of NEWS is to build upon the idea of a wiki in the direction of a CMS. Or, to put it another way, to considerinstead of that a wiki-style system of formatting and interlinking is not an end unto itself, but a means towards something more powerfull. NEWS aims to be that something. (sounds horribly like a mission statement from a high profile CEO, right?)
So, Lets look at permissions...
Permissions
Within NEWS, we wants to keep the permissioning fairly simple. Remember KISS. So, let's propose a simple heirarchy or control: For each page let's propose the following possible access levels
- No access (= page is hidden)
- Read only
- Edit (implies create)
- admin (rename, change access, etc)
(in unix chmod terminology, we might consider these to be roughly equivelant to modes "---", "r--", "rw-", "rwx")
Now each level can be set independantly for each class of user:
- anonymous (not logged in)
- generic logged in user (what an "anybody who is logged in" gets, unless the following rule applies)
- specific user (ie, set a specific level for a specific user)
(in chown terminology, we have: world, group and user - with the difference that multiple users can be each set their own access level)
Now, a traditional CMS system has the access controls as:
- anonymous can read
- logged in can read
- admin/specific users can edit and/or admin
A traditional wiki has the following difference:
- anonymous can edit
- logged in can edit
NEWS intends to allow any flexibility, but considers a sensible default to be that
- anonymous can read
- logged in can edit
In this way, by default, edit permissions are not granted wholesale to any joe who loads the page, but ARE granted to any joe who goes to the minimal effort of creating an account.
Of course, for any given page, these controls can be changed as needed. Open a page up for complete wiki-style, or lock it right down for a user-created-content driven site with no reader interaction at all!
Now, we consider that permissions granted are inherited to any subpages, unless a new permission overrides it. Thus, for any given user on any given page, we find out his permissions by asking for the permissions for this page - and if none found, requesting permissions from the parent page, and so forth (note that like a filesystem, NEWS imposes no limit on the depths of a page tree).
Admin access
The question here is simply - what can an admin do? (note that some of the items listed here may be possible by a regular user if they have the permissions to do so - but the admin controls grant shortcuts - eg, deleting a tree, rather than editing each page in the tree to zero content as a user would have to do)
- alter permissions on the page
- revert a page/tree to an earlier version
- move page/tree to an alternate location
- delete page/tree.
- note that this should not remove the data, merely it reverts a page to a zero content status - the rest of the wiki engine will now get the "?" editlink for that page. Retaining the data allows later reversions.
- edit the "box" settings. (ie, pages that are included to the page in a sidebar or other "secondary data" means)
- note that like permissions, box settings are untouchable by a regular non-admin user, and like permissions, are inherited to subpages)
- embed PHP directly into a page (note that this is effectively another user-access level). Embedded and executable php wityhin a wikipage is the NEWS method of modules. As the php code is being executed, it should know it's environment (ie, is it primary content, or secondary?).
(see more below)
Site structure
The basic structure of NEWS is the tree - one parent with many children. This follows the basic (dare I call it instinctive?) structure that modern filesystems use. The aggressive inter-linking system provided by the wiki core helps ensure that this basic structural skeleton is not too dictatorial. Besides, for best wiki exploitation, there should be a minimum of categorisation. (ultimately this is a users/admin system, and depends how wiki-like or cms-like (or blog-like, or whatever) you want to make NEWS. For my own purposes (which is why I'm designing NEWS!), wiki-style with a dash of CMS is the intent. (and a pinch of blog and gallery too)
The NEWS data tree is not directory and file based as a unix file tree is (ie, data only exists in files), but is page and sub-page based. ie, data can exist in "page" and also "page/subpage". Since at some point the wiki data may need to be translated to a unix-style file tree, a translation mechanism is nescessary. See NEWS/Implementation for more details.
Editing and commenting on pages
The wiki style is to edit a page directly with revisions/comments , rather than make a seperate comment - which is more CMS in nature. (think of a guestbook maybe :)
NEWS should support both - if a page is editable to the user, then the relevant link is "Edit this page", otherwise the user is presented with a "Comment on this page" link (this would open a "Comment#" subpage which would be read-only after creation.
Secondary information
Often there is supplementary or secondary data that may accompany primary data. NEWS intends to support such data by what we'll call "boxes". (The name deriving from the idea that secondary data is most likely to be displayed in a series of boxes in a sidebar. Slashdot is a good example of this)
Within NEWS, a box is no different to a regular page - and in fact may be a regular primary content page in other contexts - and (through the use of embedded php) may even display different content as secondary data rather than primary.
The control of which boxes to display is controlled by NEWS-CL (see /textformatting). Boxes may be set as genetic - which means that once a box is enabled, it is enabled for all subpages also - unless explicately disabled further down the tree of pages. By default however, they are not genetic. To discover what boxes should be included to a page, a top-down search of the tree is performed. (by comparison, a bottom-up seardch is performed for discovery of permissions for a page)
Modules
NEWS plans to implement modules in a simple, flexible, and scarily powerfull way.
- PHP may be embedded directly in a page !!!
Obviously, this needs some control - the proposal is that PHP code be identificable within the system by wrapping it inside <PHP>...</PHP> tags, and only allowing PHP to be edited by php-priv users. In fact, since with access to executable php, you effectively have god-like powers within NEWS, propose that "php" be an access level that may be set for a user within a page - effectively it's hte next step up from admin, and a step below "owner" (a level which is basically "can do anything" and only really has "can grant php access" as a unique priv beyond php access. (which in itself is only "can edit php in a page" access above regular admin). In this way PHP access may be granted directly to a specific user for a specific page. (note that this is basically a security hole - the user could write php to grant themselves addedd access within NEWS system anywhere. So grant PHP privs VERY sparingly!
If the php code can be 'protected' from the rest of the NEWS system in some manner, then this would be worth looking into also. (say, a php-chroot ;)
- PHP code may be used to create:
- Poll Booth page
- Planner/calender/diary/journal (blog)
- Image/file gallery (and thumbnail preview box)
- Recent Changes
- RSS output
- Index/site tree (also perhaps a graphical page-connection scattermap?!)
- Bookmarks page (ie, search the site for all external links)
- Directory listing (so, for eg, when you request "FOO" you get this page, but when you request "FOO/" (for example), you simply get a `du` or `tree` like listing of the page and subpages available.
- TODO list (ie, show all pages references but not yet created)
- backlinks page
- E2-style observance of link following to strengthen links between pages!
Users
What userprefs should there be?
- Timezone (NEWS should consider all dates internally to be time_t)
- Theme
- email address / homepage
- Editbox size
- secondary information to include when viewing pages
- Pagewatch option (overkill?)
User prefs should be written in NEWS-CL, and stored in the NEWS-CL fork of the page for the user. (and here we introduce the idea that every page has a data fork and a metadata (=control) fork. How Macintosh.
You may only edit the control fork if you have admin access to the page in question.
Note that this means that an admin on a page can edit the user with the same name as that page. I think this is unlikely to cause problems however.
Suggestion:
While not totally a user prefernce, it may be nice to have multiple timzones; that of your own, that of the whoever has made a post/modification; and that of the server. I find that knowing what timezone the other person is in relative to yours not only you to understand what situation the other user may be in, and when things occured for them.
It will help when it comes to tailoring posts to a discussion, and allows other to get the context of certain situations that may not be apparent if they reside in a different timezone.
Perhaps even a "buddy timezone" display may a nice preference, however, that it probably more of a feature that would be useful in a forum :P.
Nemo writes: yeah, timezones should be trivial. Just give the logged in user a 'local timezone' option to set, and adjust any time to be displayed appropriately. It's a nicety not essential to the system (which is why I'd not mentioned it), but would be the sort of thing that in the long run would be the 'Correct Thing To Do'.
More reading:
