Welcome to subsite

Subsite is a wiki to build collaborative websites. Unlike other wikis, Subsite does not only save its pages in the SVN, but it is the SVN. Therefore subsite is also a SVN frontend, intended to make SVN usable by people who are not experienced computer users.

This page tries to teach you what makes subsite as special as it is and why the world needs another wiki system. Keep an eye on the definition list at the right. At last I'll present some other concepts as well as more future plans.

subsite in planning
Please regard that the software subsite has not been programmed yet. This page serves as a collection of ideas.

What is Subsite?

Subsite is a topic for a versatile web framework written in Perl. The following list tries to cover what subsite can do for you.

SVN frontend: Subsite can manage multiple SVN reposities. It does not want to rule your reposity, but accepts every directory layout. In the directory /.subsite, it will save some configuration and then you can go off and use your reposity in subsite. SubSite will give you access to all file operations (moving, creating, deleting, ... files).
WebSVN: Subsite also provides a very simple WebSVN like system which even enables inexpererienced users to browse their homepage folders and get an overview over the last changes.
Wiki: The basical idea of subsite: Implementing a wiki system. Like all wikis, it is easy to use and can be set up to allow everybody to modify pages. But unlike any other wiki, the subsite wiki can do even more: It is independent of file types, so you can edit every type of file, not only text and images. Additionally, it is independent of markup languages, so you can choose freely if you want to use MediaWiki syntax or MoinMoin syntax, LaTeX or RTF, HTML, SSI, PHP, Perl, etc. pp.
CMS: As Subsite provides excellent facilities to manage your directory structure and files, it could even be seen as a CMS. The possibility to review and commit your changes back to the reposity manually emphasizes this impression.
Good old FTP: Subsite can manage magic directories (which are e.g. accessible by FTP). If a user loads up some content to these directories (that means if he changes anything), subsite will recognize that transaction and subsequently will try to merge these changings to the reposity automatically. If a merging conflict occurs, it can be solved easily in the web interface. In this way, conservative users can keep their local directories with the homepage and continue updating stuff with their favourite FTP client without paying attention to the SVN.
Static homepage & Perfomance: The subsite system is designed to be as perfomant as possible. Therefore it does not need any database or comparable administration overhead, apart from at least one accessible subversion reposity. The final homepage will be exported automatically in a static directory which will be accessible like an ordinary homepage by the web.

Why Subsite?

How FTP typically is used in a single user environment

Private homepages are often managed with a simple FTP program to load up new content to your web project. This setup works well as long as you work alone. With only one other person, there are two concurrent local installations on two computers and if you don't watch out like hell you will overwrite your changes at each other the whole day long.

This problem is a very old one, it appeared especially at software development, where multiple programmers work at only one source code file. Of course there are already solutions for this problem – there are even many different solutions for collaborative websites. Unfortunately they all did not match my criteria; I'll present you know three basically different ideas and their hitches.

System	RCS	Wiki	CMS
Scheme
Abstract	Revision control systems are powerful pieces of software intended for software development, but also suitable for websites, as they mainly consist of text masses (HTML pages, CSS markup, ...). One of the most widespread revision control systems is Subversion (SVN), the inofficial successor of CVS.	Wikis are web pages which can be modified by everyone, using a markup language much simpler than HTML. Wiki systems are the perfect tool to create collaborative websites and almost every implementation can be configured to accept only a small group of known editors to modify the wiki content. I've tested multiple wiki implementations, i.a. PmWiki, ErfurtWiki, ikiWiki. In my opinion, MediaWiki (the one that Wikipedia runs) is the most powerful wiki engine on earth.	Content Managament Systems are special web systems which manage your homepage for you. They are simple in use and can have powerful features. Compared to the wiki system, CMS usually can export pages statically.
Pro Contra	Most powerful revision control Powerful merging system Great overview about progress (with software like WebSVN) Horribly complicated and too dificult to understand, above all for unexperienced computer users	Very simple, ideal for unskilled persons Simple markup syntax No more direct control of sourceode and storage structure – consequently dirty HTML source code and intransparent heavy databases. MediaWiki is huge and does not run perfomant on feeble servers. Unfortunately none of the other wiki systems is comparable to the functional range of MediaWiki. Due to the lack of an export function the perfomance is quite bad because most private sites are not edited very often, but the wiki system must run on every web access.	More powerful managament of site structure, compared to the wiki More performant due to static export of pages Simple to use, thanks to WYSIWYG editing Like the wiki system, most CMS produce dirty pages like Frontpage, espacially if you use techniques like WYSIWYG. Like the wiki systems, CMS are heavy in use and need intransparent storage databases.
Concolusion	SVN doesn't match the criteria because unexperienced users can not work with such a complex system.	Most wikis don't match the criteria because the systems scale badly and save in intransparent structures.	CMS don't match the criteria because by using such software, we get back to the times when everybody used Frontpage to create his homepage.
subsite's improvements	subsite makes SVN ready for unexperienced users.	subsite saves it contents in a SVN and fits to every directory layout.	subsite won't make the content – you don't have to relinquish your files to some redmond system which want's to manage your life.

How subsite works

The subversion reposity will be the central part of your subsite installation. Everything a visitor on your homepage sees is always the latest version from this reposity.
From your point of view (client-side), there are three major ways to modify the content of your homepage: You can use a simple SVN client and work with the reposity like with any other. Everytime you commit your changes, they will be immediately exported to the public web directory.
If you are more conservative and – on the one hand – want to keep your local homepage installation, but &ndahs; on the other hand – don't want to have this SVN managament overhead, you can keep this directory and use the magic FTP service. At that time, the subsite system firstly comes into one's own . Everytime you upload a file, subsite will check if it can be securely commited or if it needs to be merged to the reposity with manual help, which can be given on the web interface in a very easy way.
At last there is the wiki way where you can edit the content of your website directly in your browser without even touching your local hard disc. This wiki is the central point of the subsite system. According to the settings of your wiki, the subsitewiki will commit every single change (each edit on one page) or will collect all your changes and publish them in one go.
Of course the wiki also features everything else normal wikis do, especially page history, which is mainly done by falling back on the subversion application.

Find out more about subsite

The following internet sites might give you more information about subsite, but perhaps only in German:

technikum29 development wiki: SvnWiki – svnwiki was the name of the first draft after I renamed it to subsite (to emphazise the targeted framework system). The article lists central pillars from the concept, as well as a dissociation from other existing wiki implementations. At last the datatype structure is presented which shall be implemented by svnwiki/subsite respectively.
As a typical open source project, the sourcecode of subwiki shall be published in a SVN reposity as well. Keep an eye on technikum29 development: WebSVN.