OpenWetWare:Software/Subwikis: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
Subwikis is a different solution from having private pages on openwetware but I believe it solves all the problems with private pages (and more). It also touches on the issue of the openwetware software distribution. The basic idea is to host wikis for others. Subwikis on OpenWetWare is technically possible and already implemented using unified OWW login (through OpenID). | |||
We have *.private.openwetware.org be a place for subwikis. People can request a subdomain, let's say SUBWIKI so they can go to subwiki.private.openwetware.org to get to their wiki. The subwiki can be setup however one wants such as regards to permissions. A subwiki can be completely private (i.e. requires login just to read), can be like openwetware which requires login to edit but the user list is controlled by someone else (so essentially a lab can lock down pages that only they can edit), or can be public to anyone with an OWW account. For example, check out the [http://test.private.openwetware.org/ test wiki]. Everyone with an OWW account can log in to edit that wiki (i.e. it has same permissions as the main OWW wiki, except that it's completely separate.) The test wiki demonstrates the OWW login mechanism. | |||
On the technical side, creating and managing the wiki is easy. To create a wiki, run on the server <tt>/data/web/admin/createwiki.sh. <wikiname> <oww_user></tt> where wikiname is the new wiki name (e.g. test) and oww_user is the OWW username that will become the sysop of the wiki (e.g. austin). The script does the following: create a new mysql user/password, a new directory to store the subwiki's file uploads (images directory), and a wiki configuration file that includes the database username/password. The subwiki uses the same mediawiki installation as openwetware and inherits the same configuration file (including extensions). Of course anything can be overriden by the wiki specific configuration file, but the default is to create an empty, completely separate wiki in terms of database and uploads, yet uses the exact same code base and shares the same settings. | |||
Benefits: | Benefits: | ||
* Requires minimal work on the back-end to setup for us | * Requires minimal work on the back-end to setup for us | ||
* Essentially no extra work for subwiki maintenance (i.e. upgrades) | * Essentially no extra work for subwiki maintenance (i.e. upgrades) | ||
* | * Almost single sign-on with openwetware (could possibly make it single sign on) | ||
* We share and make better use of our new server resources (network reliability, backup, etc.) | * We share and make better use of our new server resources (network reliability, backup, etc.) | ||
* Can automatically move existing wikis to be hosted by openwetware | * Can automatically move existing wikis to be hosted by openwetware | ||
Revision as of 13:07, 6 December 2006
Subwikis is a different solution from having private pages on openwetware but I believe it solves all the problems with private pages (and more). It also touches on the issue of the openwetware software distribution. The basic idea is to host wikis for others. Subwikis on OpenWetWare is technically possible and already implemented using unified OWW login (through OpenID).
We have *.private.openwetware.org be a place for subwikis. People can request a subdomain, let's say SUBWIKI so they can go to subwiki.private.openwetware.org to get to their wiki. The subwiki can be setup however one wants such as regards to permissions. A subwiki can be completely private (i.e. requires login just to read), can be like openwetware which requires login to edit but the user list is controlled by someone else (so essentially a lab can lock down pages that only they can edit), or can be public to anyone with an OWW account. For example, check out the test wiki. Everyone with an OWW account can log in to edit that wiki (i.e. it has same permissions as the main OWW wiki, except that it's completely separate.) The test wiki demonstrates the OWW login mechanism.
On the technical side, creating and managing the wiki is easy. To create a wiki, run on the server /data/web/admin/createwiki.sh. <wikiname> <oww_user> where wikiname is the new wiki name (e.g. test) and oww_user is the OWW username that will become the sysop of the wiki (e.g. austin). The script does the following: create a new mysql user/password, a new directory to store the subwiki's file uploads (images directory), and a wiki configuration file that includes the database username/password. The subwiki uses the same mediawiki installation as openwetware and inherits the same configuration file (including extensions). Of course anything can be overriden by the wiki specific configuration file, but the default is to create an empty, completely separate wiki in terms of database and uploads, yet uses the exact same code base and shares the same settings.
Benefits:
- Requires minimal work on the back-end to setup for us
- Essentially no extra work for subwiki maintenance (i.e. upgrades)
- Almost single sign-on with openwetware (could possibly make it single sign on)
- We share and make better use of our new server resources (network reliability, backup, etc.)
- Can automatically move existing wikis to be hosted by openwetware
- Easy to move pages (manually and perhaps automatically) from subwiki to openwetware.
- People no longer need to maintain their own wiki/extensions and trying to match with openwetware. All subwikis immediately get all mediawiki and extension upgrades
- We've also talked about perhaps using the hosting of private wikis as a means of supporting the public wiki (i.e. some fee for us hosting the wiki).
