Individual Movable Type instances
From ETS
Contents |
The Idea
Version 1
In order to give users more flexibility in managing their blog space as well as more options with protecting content (see blogs and protected space), a new scheme was was developed for the implementation of Movable Type at PSU. It would consist of each user getting two instances of movable type which they can have complete control over. When a user would login at blogs.psu.edu, they would be directed to a URL for their own instance of MT. The URL would contain the user's ID, like blogs.psu.edu/xyz123/mt.cgi. There would also be a link added to the MT interface that would lead users to their protected blogs, which will live in a different version of MT located at a URL something like blogs.psu.edu/protected/xyz123/mt.cgi. Only one copy of the application files would exist on disk, and all the various urls would run this one copy of the code. This effect could be achieved with symlinks or perhaps some form of apache trickery.
MT would use a different DB for each instance. MT will know which DB to use based on the URL used to access to application. This effect should be easy to achieve since mt-config.cgi is perl code. We may start using sqlLite for the DB, stored in a user's PASS space. For many small DB's, this may be more efficient than setting up many mysql databases.
The instance of MT that publishes to a user's protected space will also have to be protected by the web server. Possibly it will read info from an .htaccess file in the protected webspace?
Version 2
Actually install MT into a user's personal space, and allow them to manage it. This work similarly to typical web hosting setups such as dreamhost. This route seems less like a hack, more maintainable over time, and the methods used here can transfer to offering other web-based software to students, faculty and staff. One other advantage of this idea over version 1 is that a user can create multiple instances of MT for different private blogs in the protected space.
- Need auto installer script.
- script will install MT application into personal space, create sqllite db, autogenerate config file.
- script must configure web server to protect certain scripts by webaccess and limit to user and leave others open.
- Some kind of virtual host setup where that can limit where files can be read/written.
- limit the location a user can specify where a db file can go.
- allow users to create their own blogs, but restrict them to their own space.
- this should be done from web server level, users will be able to adjust code in application.
The Benefits
- Users will be able to have a protected instance of movable type for non-public content.
- It may be possible to allow users to install their own mt-plugins by placing them in a special directory in their PASS space. Then again, maybe not. See unresolved issues below.
- users will not become confused by finding other user's blogs in the main blog listing. It will be much easier to manage your blogs.
- Allowing each user to be admin of their space will allow them to delete their unused blogs.
- Just commenting on a blog will not make that blog show up on the commenter's drop down list.
- If MT is running from a sqllite DB in a user's pass space, a user could take that DB with them to another server when they move on from PSU.
- User management. User's blogs and data will be cleared when his or her personal space goes away
The Drawbacks
- If blog data is stored in many small dbs, when it would not be practical to mine for cross-blog data, such as most popular posts, tag search, recent comments across all of the blogs@psu. It seems like we would not ever do that anyway. This functionality would be provided by whatever aggregation tool is eventually deployed to work in conjunction with blogs@psu.
Unresolved Issues
- What about when we update the software/plugins? How do we run the update to everyone's DB?
- can we actually allow user's to use their own plugin? Wouldn't this allow them to run code on blogs.psu.edu?
- how will MT perform with sqllite/GPFS
Issues that this setup would not address
- comments and authentication must make sense in a webaccess world. We currently hack the core to make this work
- Customizing blog templates to include widget manager support, podcasting.
