MCAL: libmcal History

libmcal History

libmcal started when we needed a decent calendaring system for Bizchek. We hade already standardized on PHP for our web interface, and had in fact written a number of modules for php (imap,aspell), it seemed only natural to create a calendar module for PHP.

Our choices were to either use what 90% of the current web calendaring apps use, which is some form of a proprietary calendar storage solution, usually rooted in direct sql calls. From our experience, this is a solution that is very non-scalable, preformance hindering, and difficult to expand. from our history with web based email, we knew that a solution that incorporates backend calendar servers was a necessitity.

The other influence we had was through our opensource experience, we knew that if we were to go to the trouble of making a standards based calendaring system, theres no better way to do it than to opensource the project.

Looking at the very few publicly acknowledged calendar schemes (http://www.imc.org/ietf-calendar/), we chose a current internet draft, ICAP. This was because of it's much more intuitive specs, it's close ties with the imap protocol, and it's expandability. Although CAP is an ISO internet draft, and is backed by the IETF Calendaring and Scheduling (calsch) Working Group, we did not feel that it encompassed a protocol that could be easily used and expanded. In fact, there is not a single application that uses CAP.

libmcal versions

We started off making a simple client-server calendar library. something that would easily facilitate programming either a client or a server from a single set of library code. Our first version actually worked fairly resonably, but we very quickly learned that it was not expandable enough for our needs.

We then decided to write a set of code that would incorporate plugable storage drivers. This enabled us a few very big advantages that we hadn't considered. by having plugable drivers, we could easily make calendar functions that not only used icap, but also local storage. By doing this, an icap client would simply be a client that uses the icap protocol driver, and an icap server would simply be a client that uses some local file storage driver. By programming the library correctly, these driver can then be easily removed or added, so that a client could simply use local file storage instead of an icap server, or even an SQL server. It's quite ironic because we have been programming in using the c-client library for quite a few years now, and had decided when making the first set of code to try and move away from c-client's complexity as much as possible. We now found ourselves almost completely emulating it!

Our plan was to use C++ to write libmcal. C++ is a little more made for this factory type programming, in which pluggable drivers use abstract classes to define and maintain relationships between objects. c-client in fact does a lot of work to emulate this in C. Two difficulties we had were that we mostly are C programmers, and know C a lot better than C++. Also, PHP is programmed in C, and in order to interface with it easily, we would have to make a C wrapper around the C++ classes and methods. Suffice to say, 2 days later, we converted the C++ back to C :^).