Just finished getting Scooby / Cosmo setup in a development environment, then got Selenium on.
Modified the first Selenium test TestOpen to run against scooby and it worked :).
You can see it here
The latest status overview, with quick high points from every project and overall highlights, can be found here.
During last week’s sprints I was asked to see how easy it was to import mail into Chandler from a local mailbox. Thanks to Python’s mailbox and email packages, the mailbox parsing was trivial. Similarly, Chandler’s domain model can represent email items and has a number of APIs that make creating such items from a raw email string very easy.
It’s been a while since I posted anything on the chandlerdb blog. That is now corrected with a few new posts about repository backup, recent performance improvements and version purging.
Chandler’s repository is versioned. Like a subversion source code repository, changes to items are saved into the repository as coherent versions. This enables to later merge together changes that occurred in different threads or processes instead of serializing changes by locking resources.
In the run up to the Chandler 0.6 release, a lot of performance improvements were made to the repository codebase. Many areas of Chandler were also reworked somewhat to make better use of performance critical repository features.
Chandler’s repository is intended to store a lot of data that one cannot afford to lose. It should come as no surprise that doing regular backups is strongly recommended. There are a few repository APIs, currently accessible from Chandler’s “Test” menu or from Chandler’s --restore command line option, that make it possible to backup and later restore a repository’s files.
In the past few days we’ve gotten some kind mentions on BoingBoing and ArsTechnica. It’s great to see that people are interested in what we we are doing.
Unfortunately, there are a few factual errors in both articles. I’m sure that this is partially due to the long history of Chandler, and also to some of the very early articles about the project. The Chandler project has attracted a lot of attention, but a lot of things have changed over the course of the project.
Probably the largest error has to do with the role of Andy Hertzfeld. Andy was one of the original members of the Chandler team, and was one of the contributors to Vista, but he hasn’t been active on the Chandler project for a few years. Chandler as you see it is very different from Vista.
The world is looking for a competitor for Exchange, or so it seems, and that rubs off on us. Chandler didn’t come in to being with the purpose of competing with Exchange. It came into being because Mitch wanted a solution for small groups of people. Our initial target audience for Chandler is small workgroups. After that, our goal is supporting university scale usage.
There also seem to be some misconceptions about the size of the OSAF staff. Today there are 23 people on the Chandler development team at OSAF, including a full time UI designer, a QA person, and some managers. In addition, there are 5 people working on server related projects: Cosmo - a CalDAV sharing server, and Scooby, a web based calendar access application.
The current version of Chandler, 0.6 is focused on producing a usable calendar. Most of the work went into the calendar and not very much went into e-mail. The work that we’ve done so far is mostly under the hood. There’s support for IMAP and SMTP, which will work with Internet standard e-mail, so it’s not limited to a Chandler workgroup. We have yet more protocol level work to do, and there’s lots of UI work that remains to be done.
There was one important message that didn’t come across in either posting. We are looking for participation in the project. That means feedback on features, bug reports, bug fixes, other contributions, documentation, and so on. Please come visit us on one of the mailing lists, or on IRC.
She is joining the design and program management team and will be working on projects that cover all the OSAF products (Chandler, Scooby and Cosmo). Read more about Priscilla on the People page.
Earlier this week I represented OSAF at the 4th CalConnect Interop. This entailed spending a day and half in a room with a bunch of other calendaring vendors, trying to make sure that our software works with theirs.
Most of the work I did involved CalDAV client-server testing. Besides OSAF’s own Cosmo, there were servers from Novell, RPI and Oracle to test against. It turns out that these servers work sufficiently differently from ours that they exposed interesting and useful bugs in our CalDAV client implementation.
Two other CalDAV clients besides Chandler were represented: Mozilla’s Sunbird client, and Evolution (with CalDAV plugin). Brian Moseley had set up a machine at OSAF where he could debug a test server, and was available on IRC to help diagnose problems. Both Evolution and Sunbird use a different method of downloading events from a CalDAV server than Chandler, so Brian (with the help of Bobby Rullo) was able to chase down a couple of good bugs.
In the remaining time, I was able to squeeze in some testing of interoperability of ICalendar (.ics) files with other vendors, including Novell Groupwise, EVDB and Trumba. This, too, turned up a couple of interesting bugs.
All in all, it was very helpful to devote some time to interoperability, especially in an environment where you can discuss issues with other developers, and, in some cases, resolve or work around them. Thanks to CalConnect for organising, and to Novell for hosting us in their lovely Executive Briefing suite.
Except where otherwise noted, this site and its content are licensed by OSAF under an "Attribution Only" - Creative Commons License.
Powered by WordPress