Master’s Project: Distributed Content Management System
Posted by Jim at October 6th, 2004
So, I mentioned recently that I’d probably put my master’s project description online sometime. This is it.
It’s basically a content management system for a website. With any luck I’ll be able to finish before the semester ends.
One cool thing about working on something like this after being in the master’s program and having a few years’ experience under one’s belt is that I’m finally to a point where reading the documentation for the tools is no longer intimidating. It’s nice to be at a point where I don’t get stopped by concepts that are completely unfamilar but totally basic to the technology.
Now I get stopped by new and unusual concepts.
Looks nice, Jim. Good idea to try to build something that would be useful to you at work. A few ideas…
1) Your project summary suggests that a method of communication be supported, but it doesn’t specifically mention a strong association between such communication and the documents themselves. I think that association would be extremely helpful (similar to the commit comments of CVS).
2) The concept of branching seems to confuse non-techies. Maybe that could be dumbed way down and made logically parallel with the document states you mentioned, on a document-by-document basis:
* 1 published document
* n publish candidates
* n archived
Perhaps that is what you intended with the “current”, “future”, and “past” branches, respectively; but did you mean that in the sense of version branching per document or, instead, as branching of the site as a whole?
3) It looks like you’re trying to keep away from a master server (which is where you’ve got the big departure from systems like CVS). So, you might need to make up for what gets lost when you distribute the system. For example, perhaps a future add-on could be a back-up agent that makes a copy of each file via the P2P on a schedule.
James
Good thoughts. The concept of branching is one that scares me somewhat for precisely the reasons you mentioned. It’s not a very intuitive concept for non-techies.
So I’ll respond to your points in the order you made them…
1. If I find I can implement a mode of communication about individual documents within the time allotted (this semester), I will. It seems helpful to me too. The ideal would be within the document itself (so you can see changes people have made or questions they have). More likely, there will be an associated text file conversation about the document.
2. My original idea was to have the current/future/past refer to the site as a whole, but it might refer to documents within the branch as well. I’m still fiddling with the details of this. My advisor recently convinced me that I should find a way to use a version of cvs with this instead of rewriting cvs as part of this program. Thus, I’ve found a gpl’ed version of cvs that works on windows, macs, linux and freebsd. Hopefully I’ll be able to construct my cvs interoperation layer fairly quickly.
3. My project description is probably unclear on the master server issue because I was unclear until recently.
I’ve got a rather horrifying mixed architecture planned. It’ll be peer to peer in that everyone can take a look at the documents everyone else is working on, make comments and so on.
At the same time, I’ll have a “cms/cvs server.” At the point that people want to submit a candidate for publishing, it goes there and they put it into the appropriate branch.
At least that’s what I’m thinking at the moment.
Jim Zoetewey