September 28, 2007
CoSign on board
I've finally had a chance to finish the CoSign authentication module for the Zend framework. That was the last major UM-related hurdle before I could begin developing Sites applications in the framework. CoSign is quite easy for developers to use. However, I had to study the framework to find out how to package the code and where to "plug it in". In the process, I learned a lot about the framework.
The nice thing about my CoSign module is that it is completely reusable between Zend applications. Also, since CoSign only handles authentication, my module allows various authorization mechanisms to be plugged into it. For example, I plugged in a database table for authorization.
The first Sites applications where I plan to use my module are Scheduling and Inventory.
September 26, 2007
Web Development with the Zend Framework
At Sites, we rely on web applications to manage our infrastructure and the people who maintain it. We also use web applications to leverage our infrastructure to provide new services to the campus community. In the past, we used a variety of languages. More recently, we have settled on PHP as our language of choice. As our experience with PHP grows, the quality of our applications improves.
In order to continue to improve the quality of our PHP apps, we're now beginning to use the Zend Framework in future development projects.
A framework is a set of pre-written code modules, but more importantly, the code modules are designed to facilitate a programming methodology that we hope will:
- Improve the security and stability or our applications
- Standardize our programming environment so that each app is easier to maintain and each application can communicate with others
- Add logging and improved error handling where appropriate
- Add documentation to help current and future developers
- Reduce programming time so that we can focus more on features and the UI
The most challenging part of the Zend Framework is that it is new and documentation for beginners is scarce. However, it's a solid framework created by the company who created PHP, so we think it's work the effort.
We're making progress in our first Zend Framework assisted application. We have database interaction working and Cosign authentication is almost ready.
September 24, 2007
mPrint is officially released
It seems silly to say since mPrint (http://mprint.umich.edu) has been around for years now, but we've finally gotten to a point where we are comfortable doing an official release and advertising campaign.
We had gone from very beta to sorta beta to sorta released and then hung around at the 'sorta released' phase for about a year. The thing that finally pushed us to start officially advertising was the added support of Microsoft Office formats.
Here are The University Record and Michigan Daily articles about the roll out:
For those who don't know, mPrint is a web application provided by Sites that allows students, faculty & staff to upload jobs and print to Sites managed printers. Jobs printed this was are charged to users BCP allocation. Until this summer we only supported uploading PDF and PostScript files. We require people to upload jobs (as opposed to printing directly to the print service) because we need to verify their identity. A CoSign protected web page lets us do that.
In order for mPrint to support different file formats, it needs to be able to convert files from the submitted format to something printers or our print server(CUPS) can handle. In a normal printing environment your client application (Word/Excel/PhotoShop/etc.) does that for you. The print server has no understanding of these formats. This is why we had users convert to PDF or PostScript for so long. Those are formats the server understands.
Unfortunately this was a huge limitation. Having to convert to PDF before uploading just didn't cut it. It interrupted the user's workflow too much. So we hit upon the idea of moving the client conversion component to the server. Since the majority of our printing comes from Microsoft Office, we thought we'd start there. We just couldn't come up with a workable solution for having our linux-based servers convert Office file formats. We thought about running print jobs through OpenOffice but didn't trust OpenOffice's rendering of Microsoft Office documents to be 100% robust. We thought about using WINE or one of CodeWeaver's products, but we had no experience with that and it felt a little kludgy.
We ended up building our own somewhat kludgy solution using components we are very familiar with. In short, the web server receives the uploaded job and sftp's it over to a Windows server. the Windows server is running a service that picks up the job, converts it using Office's COM objects and sends it back to the print server. For most jobs this takes less than 10 seconds and is quite effective. The best thing about this solution is that it doesn't just limit us to Office file formats. Within the next month or so we should be able to support various image formats (through PhotoShop) as well as AutoCAD file types.