September 2003 Archives
September 19, 2003
Automating the blog creation process
Bill continues to work towards automating the blog creation process. I came across this link today which may help both ourselves and others interested in hosting multiple blogs on a single server:
Also, there is a fair number of universities waiting for the release of MT Pro, which was supposed to have been released this summer (Summer 2003). According to the press release MT Pro will have a bunch of new features, including better author management. I know Stanford is waiting for MT Pro to come out before they launch their campus wide service.
September 16, 2003
So far ...
So far, so good. Bill has been working on setting up our x.500 system as the authentication method of choice for users to both create a blog and log into the MT system. MT blogs are created kind of uniquely in that MT expects the user to first create the web directories that will hold the blog site proper. In other words, before a user can create a blog, they must first create the directories on their web server that will host the blog that everyone sees. The must also give those directories the right permissions so that MT can write to them. What we are trying to do is automate that step so that the necessary directories are created on the fly.
Of course, it's not really as simple as that. MT is actually a pretty complex piece of coding. However, we have to take out this complexity so the most novice of user can easily create his or her own blog. Here is what we envision:
- The user is asked for their x.500 Internet ID and Password
- Upon authentication and authorization the system looks to see if the user has already created a blog. If so, they are passed into the administration interface for that blog.
- If a blog has not been created for that user they are passed to another interface that asks them:
- What do you want to name your blog?
- What do you want to name the directory for your blog?
- The system then takes this information and:
- Creates the main web directory for the blog
- Creates the archives directory for the blog
- Creates the initial database entry for the blog in the MT MySQL database including the necessary configuration information
- Creates the user information in the MT MySQL database including the right permissions to access and modify their newly created blog
- The user is then forwarded to the main menu screen of MT where he or she can begin modifying the blog.
Sounds easy, right? Yes and no. The x.500 authentication is proving to be a little more sticky then expected due to the fact that every transaction within the admin module for MT essentially reauthenticates a person. What Bill has to do is figure out how to force the MT system to use x.500 (or the Central Auth. Hub) rather than MT's built in authentication system. I think he's on the right track, though.
September 12, 2003
Technical Issues / Things To Do
On Monday, September 15 we will begin hacking the MT code to make it work for our goals. This is both exciting and a little daunting. Next week will give us a really good idea of whether or not we have the time, resources, and ability to achieve our goals. Here are some of the things we are going to try to figure out next week:
- Can we configure MT to work with our x.500 authentication system? Ideally, we'd like students to be able to create and/or modify their own blogs using their university maintained Internet ID and Password. However, a lot has to happen coding wise to make that happen.
- In order to create a new weblog using MT, the user must first create the web directories that MT will write the public version of the blog to. In addition, these directories must be made chmod 777. We've got to figure out how to do this on the fly.
- Related to this issue then is a policy issue: what do we call the initial public directory? The easy answer is to name it after the user's Internet ID. My public directory would be called /snackeru/ then. However, that's no fun. Users should be able to name their blog and the directory it sits in anything they want.
- When a user account is initially created, that user is given permission to post to a particular blog. We have to figure out how to create the blog and the user at the same time and give the user the proper permissions to have complete control over their own blog, but not anyone else's.
- How will we handle multiple authors for single blogs? The easy answer is to not allow it, but again, that's no fun. Is it possible to allow users the ability to add authors to their own blog and no one else's? Right now, it seems MT comes preconfigured with the ability to turn author creation on or off. If someone has the ability to add users, they also have the ability to assign them to any blog on the system they want. Also, if we allow people to add authors do we want to limit them to the U of M community?
- We need to set up the WEBLOG CONFIG: Core Setup section so that a user can't change the directories they have been assigned to, unless we can, again, create new directories on the fly and give individual users the power to do so. It seems like that could get really messy. Really, the only thing users should be able to do on the Core Setup page is change the name of their blog. The rest of the Config menu's seem all right (Preferences, Archiving, etc.).
It appears to me that we've got our work cut out for us. Worst case scenario is that we manually create blogs for anyone that asks and take away access we don't think they should have for security reasons. As I've said before, next week should be very interesting.
I found this on the MT FAQ web site today:
Q: Do non-profits have to pay for Movable Type?
A: Registered non-profits are not considered a commercial use and are asked, like personal users, to donate what they feel the software is worth and to maintain the "Powered by Movable Type" link on the site. Non-profits may not offer hosted installations of Movable Type, either for free or for payment.
... That doesn't look so good. Then I found this a question and answer a little ways down:
Q: What is your policy on use by schools, colleges and universities?
A: Accredited K-12 schools, colleges and universities can offer Movable Type to currently-enrolled students or staff as part of school-provided web hosting as long as there is no charge to students or staff for use of the service. Educational institutions are not required to pay for Movable Type but are asked to donate what they feel the software is worth and to maintain the "Powered by Movable Type" link on the site.
... So for now I'm going to assume we are all right. However, the two statements do seem a little contradictory. It seems MT is making a distinction between a "non-profit" and a "university."
How much space?
How big should we build the initial server? That is what our server administrator wants to know. More specifically, he wants to know the "expected disc utilization per user." I've asked a few people about this and have never gotten a definitive answer. The following computations are best case scenarios and should not be construed as something we expect, but of something we should be prepared for.
As I've said in previous posts, the U of M community is at least 60,000 users. We feel that a best case scenario is that 1,000 of these people will become users of the system. Let's say that each entry a user makes in the system is 10K in size. Movable Type writes the entry both on a web page and in the database, so that's 20K per person per day. Multiply that by 365 days, and 1,000 users, and you get 7,300,000 KB.
A user can also upload other media, such as graphics. Let's say the typical user uploads 1,000 K per week for their blog. 52 weeks equals 52,000 KB. Multiply this times 1,000 users and you get 52,000,000 KB.
Now, how long do we expect our initial server to last? Let's say 3 years. Technology moves so fast, I don't think it would be wise to go much further out (but I'll leave that decision to the server admin). So, (3 * 7,300,000 KB) = 21,900,000 KB. And (3 * 52,000,000 KB) = 156,000,000 KB. All together that is 177,900,000 KB. That is approximately 170 GB, or about 180 MB per user for 3 years.
I think the expected uploads per week per user may be a little off. And I don't think we'll get anywhere near 1,000 users to start out with. But, as I said above we should definitely be aware of what the potential is. Oh, and somebody please check my math!
September 11, 2003
Policy issues to decide
In the words of the main programmer of the project, Bill Tantzen, programming will be the easy part. Policy decisions will be the most challenging part of the project, and many policy decisions will dictate how the tool is built. What do I mean? Check out these decisions that must be made:
- How many blogs can a person have? Movable Type allows for multiple blogs, owners, and authors. Do we limit community members to one blog, or allow individual authors as many as they want? How many authors can a single blog have? Can an author be outside the University community?
- Ownership of blogs. Of course, individual authors will be the primary owners of their blogs and the content on the blogs. The Libraries are intrigued with the prosepct, however, of archiving these blogs in perpetuity. What if Pawlenty had a blog when he was a student, and his blog voiced drastically different viewpoints than he has now? Could he ask the Libraries to take down his blog, or erase problematic entries? Hopefully not. The libraries hope to provide researchers of the future a true snapshot of campus life for any given time period that blogs have been active.
- Speaking of which, how do we archive blogs? Given that the University community is at least 60,000, there is a chance that there will be many, many blogs and it will take a lot to archive these things and make them available for research.
- How long can a person have access to his or her blog? Only while he or she is affiliated with the university? Or will we allow someone to maintain a blog even after graduation? What about staff?
I could go on, and I'm sure I will. Gotta go for now...
September 10, 2003
Why We Chose Movable Type
Staff of the Digital Library Development Lab of the University Libraries inspected a wide variety of blogging software before settling on Movable Type. I would like to point out that while our first efforts will center around Movable Type, this does not mean that we are definitely going to go with this software package. We still need to make sure that we can modify it in order to suit our purposes. We need to make sure that the faculty, staff, and students will easily be able to set up, modify, use, etc. their own blogs using Movable Type. Please keep checking back for more posts regarding exactly what we are trying to accomplish.
We have inspected other blogging software applications, most notably Manila from Userland Software. This is the blogging software that Harvard is using for their project. While this software would work, and while it is relatively easy to set up and use, it is also highly proprietary. The software is written in a proprietary language, and it appears the underlying database is also difficult to manipulate. It is also relatively expensive compared to Movable Type (which is free). Given these drawbacks we decided to look for something open source, or a software package that we could modify to suit our needs.
Movable Type definitely fits the bill. It is open source; it is written in Perl and the underlying database is MySQL. It is also highly configurable both from a programming standpoint and a user standpoint. And speaking of users, it probably has the biggest user base of any blogging software. However, is it easy to use? Can we modify it enough to make it easy enough to use for the beginner, while at the same time powerful enough for the experienced blogger?
Our first order of business will be to attempt to wrap it around our campus x.500 authentication system. It is our goal to allow people to create and/or modify their own individual blog using the same Internet ID and Password they use to view email. The question is, can we reprogram Movable Type to easily allow for the creation of new blogs in this manner? According to their own documentation Movable Type can host more than one blog. Theoretically we should be able to reprogram it to allow for unmediated creation of new blogs on a single installation of the software. Of course, there are many issues associated with this effort from programming, to graphic design and usability, to policy issues.
So stay tuned. There is a lot to work on and decide.
Blogs at the University of Minnesota Libraries
Welcome to the project site for Blogs at the University Libraries. It is our goal to develop a blog server through which everyone in the the university community (faculty, staff, and student) can have access to their own individual blog. Don't know what a blog is? Well, you're reading one now! For more information on blogs in general and why the University Libraries is undertaking this initiative, please check out the white paper that started it all.
Check this site regularly for information regarding our efforts. We hope to have something for the U of M community by the beginning of Spring Semester 2004. Feel free to drop off your own comments and suggestions.