1 files changed, 4 insertions, 131 deletions

diff --git a/README.rdoc b/README.rdoc
index 29bde3d..bc1c858 100644
--- a/README.rdoc
+++ b/README.rdoc
@@ -1,135 +1,8 @@
 =CCCMS
 
-==Setup
+This is the repository for the CCCMS. Its a simple content management system 
+inspired all the good parts of different other simple content management systems.
 
-* git clone git://github.com/hukl/cccms.git
-* git submodule init
-* git submodule update
-* create a database.yml in /db
-* rake db:migrate
-* untar db/updates.tbz
-* rake cccms:create_admin_user (admin:foobar)
-* rake cccms:import_updates
-* rake cccms:create_home_page
-* ./script/server to start the webserver
+Go to the wiki to read what is all about
 
-==Documentation
-
-User stories in doc/success_stories.txt
-
-execute: rake doc:app on the command line to get a html api documentation in
-doc/app
-
-==General
-
-===Nodes
-
-The whole structure of the website is built from nodes. They live within a
-nested set structure. Therefor a given node has parents, children, descendants 
-etc.
-
-The position of a node within the nested set corresponds directly to the URL
-under which that node is accessible:
-
-  root
-      \__updates
-                \__2009
-                       \___ultra_important_news
-                       
-http://domain/de/updates/2009/ultra_important_news
-
-Note that the first parameter after the domain is the locale. Everything after
-the locale identifier is the unique path of a given node. The unique path itself
-is generated from the slugs of the ancestors of a node. The last part of the 
-unique path is taken from the slug of the node.
-
-Once a node is added to the nested set or moved within, the unique path of that
-node is generated from all its ancestors up to the root node. The computed path
-is then saved on the node object itself, allowing the system to retrieve a 
-node simply by looking for the right url in the unique_path column. This is a 
-lot faster then walking down the tree.
-
-Nodes are really just proxy objects. They point to information but they don't 
-hold that information themselves. Instead they have pages associated to them. 
-When you want to render a particular node, you actually render a page associated 
-to that node. When multiple pages are attached to a node, they act as one page 
-with many revisions. The node itself holds the pointer to current or head 
-revision.
-
-===Pages
-
-Although there is really one Page class, the pages associated to one node differ
-slightly. Obviously there is a slight difference between the head and the other
-revisions. While the head is always the most recent page which is publicly
-available, all the older revisions are only kind of a history. 
-
-Now when a user wants to modify or edit the content of the head revision he or
-she is editing a new revision instead. This new revision is considered a draft
-and has the current content of the head revision copied onto itself.
-
-====Draft
-
-A draft has an author attached to it which makes sure that only the creator of
-that draft is able to edit it. This is a form of pessimistic locking as it 
-prevents more than one user from editing and saving the same page.
-
-However, if an author should choose to abandon his draft or to let somebody else
-finish it, the author can withdraw his lock. In this case, the draft has no 
-longer an author associated to itself which enables another user to edit this
-draft.
-
-To abandon or revert a draft, the author can also delete it entirely so that 
-when another user is editing, he or she would get a fresh copy from the current
-head revision.
-
-Of course a admin user can always override or remove locks on drafts. In case
-an author created a draft but simply didn't care anymore, an admin could remove
-that draft or the lock on it, enabling other users to edit that page again.
-
-===Tags
-
-Pages of course come with meta data attatched to them. Tags are one kind of
-meta data. They can be understood and used as keywords, categories, tags or any 
-similar concept.
-
-===Templates
-
-Althought there is only one, simple and unified, template for editing pages, it 
-is possible to select from different templates for public display. This 
-selection of templates allows slight alterations of the layout. For example one
-template would display every attribute of a page (like date, author, abstract)
-while another template would hide this information away. One would show the tags
-of a page, another wouldn't.
-
-===Aggregation
-
-Keywords and other meta data can be used to aggregate any ammount of pages
-into the body of another page. 
-
-  <aggregate 
-    tags="update pressemitteilung"
-    limit="20"
-    order_by="published_at"
-    order_direction="DESC"
-  />
-
-===Permissions
-  
-The permission system is geared towards our use-case which means you won't find
-the standard create/update/destroy derived permissions.
-Every user without having any permissions is allowed to perform non-destructive
-tasks that won't affect the frontend (published pages). What am I talking about?
-
-Bob has no permissions whatsoever still he is allowed to edit a #Page anywhere, 
-because this action will only create a new revision of the #Page which is not 
-immediately published. He won't be able to manipulate a #Node in any way 
-(unique_name, slug, ordering, structure) because this would affect the frontend
-without further notice.
-
-Having a #Permission on a #Node makes Bob an admin for this #Node and all it's
-children. Now Bob can do pretty much anything on these nodes including such fun
-things as:
-  - Create/Update/Delete a #Node
-  - Reorder children of the #Node
-  - Rejecting a draft and telling the author to get his/her spelling right.
-  - Clear a stale lock on a #Node
\ No newline at end of file
+http://wiki.github.com/hukl/cccms
\ No newline at end of file