Oren’s Weblog

I spent last Thursday and Friday in Montreal for a Calendaring Roundtable sponsored by the new Calendaring and Scheduling Consortiumand hosted by Oracle.

The purpose of the roundtable was to get some of the major players in the calendaring software world
around the same table to see if we could make some concrete forward
progress towards real interoperability.

Bob Morgan, Michael Gettes (Duke), and Jeff McCullough (UC Berkeley), and I attended from
CSG-member higher ed institutions. Many of the commercial companies
with calendaring products were represented – The big-guns (IBM, Oracle,
Novell, Yahoo), the open-source community (Mozilla Foundation,
OSAF), and the smaller companies (Stata Labs, Cyrus), as well as one
other major player who did not want to be named in public communiques.
Noticeable by their absence at this gathering, though they
were invited, were Microsoft, Sun, and MeetingMaker. A person from the
Outlook group at Microsoft had intended to participate, but was told
two days before the meeting that he did not have corporate approval to
participate. MeetingMaker responded that they were not interested in attending at this time.

The meeting went extremely well – there was a great deal of enthusiasm
towards achieving short-term progress in interoperability, and people
generally seemed to be ready and willing to get on with working
together on the nuts and bolts. While it’s hard to tell whether this
will be sustained with real ongoing effort, the folks at the table
appeared to be willing to commit real resources towards this end.

There was general agreement around this table that the CAP protocol has
proven to be unworkable and may now, for all practical intents and
purposes among this group, be considered at least moribund, if not
entirely dead.

Several of the companies represented (Mozilla, Stata, Novell) have
reverse-engineered the method Apple uses for publishing calendars from
its iCal product to the web. There was an agreement to work on
documenting that method so that others can more easily implement it.

There was a very general enthusiasm for the new CalDAV proposal , and
several of the companies represented are starting to code to the
current document, while acknowledging that their implementations may
have to change as the draft evolves. It seems possible that we may see
some early test implementations as early as next spring. Future
CalConnect events will include interop bake-offs to demonstrate the
state of success (or issues arising) of this approach.

There was agreement that the activities of the Consortium would be
complementary to IETF work in this area. There will likely be an IETF
Working Group on revising the base calendar formats, and there may be
one on CalDAV.

This event will likely be followed by an interoperability event in January.

I think we all came away feeling like a log-jam in the calendaring
standards world might at long last be breaking apart, and we came away
quite hopeful.

As I reported separately, OSAF has slipped their development schedule for Chandler and have made significant changes in their architecture and plans.

During the Westwood Advisory Council meeting today, Mitch Kapor presented a list of lessons learned that I think generalizes for all sorts of development efforts, so I share it here:

Things learned

Now them’s some words to live by.

The Chandler Westwood Advisory Council met today with Mitch Kapor, Chao Lam, and Pieter Hartsook from OSAF. The Chandler folks have, unsurprisingly, found that their development timelines are longer than originally predicted. The plans now call for a 0.4 release in late October that will support a basic user interface for email, calendar, and sharing items via WebDav.

After 0.4 there will be a 0.5 release in the first quarter of 2005 that will be designed to be usable for basic individual and collaborative tasks in a small workgroup – OSAF intends to adopt that release for their own uses, hence the nickname “dogfood” (as in “eat our own…”) for this release.

The “Kibble” release, coming in the fourth quarter of 2005, will have enough functionality for use by groups of early adopters.

We had a lot of discussion about whether it would make sense for OSAF to elevate the priority of adding calendaring client functionality (using CalDAV) earlier rather than later (that of course begged the question of who was going to build a CalDAV server). The prevailing sentiment in the group was that sounded like a good idea, but we wanted some more detail on the level of effort required and which other features were likely to be deferred to make that happen.

Chao’s slides for the meeting today are available from the agenda page on OSAF’s Wiki.

On the plane flight over I was reworking one of my web sites, basically rebuilding from the ground up with content, look & feel, and navigation. I was using the latest version of BBEdit, version 8. I have to say that the more I work with BBEdit, the more I find it to be my favorite editor, on any platform. It does all the things I want to do with text and stays out of my way.

Now keep in mind that my basic text authoring approach is that most of the time I can use plain old ascii text, because it’s going to be in email. When I am writing something that needs formatting, I’m going to do it as a web page, not as a Word attachment. Why not Word, you ask? Well, for one thing, lots of people don’t have Word – don’t forget that Microsoft Office costs hundreds of dollars. But pretty much everybody has a web browser. For another thing, Word just gets in my way too much – it thinks it’s smarter than I am, which I can’t stand.

But BBEdit just puts it all in plain visible text on the screen, and it highlights markup and syntax from common languages, and it’s fast and just plain works.

John Gruber has his finger on what makes it a great application, and why the new version is a worthy update, in a recent post on Daring Fireball.

The appeal of BBEdit is in its balance of powerful text-editing features and an elegant, intuitive, and unabashedly Macintosh-style interface — and where by “interface” I don’t mean in the sense of superficial cosmetic appeal, but in the deeper, interactive sense.

Molly Baird – Brown U – Exchange 2003

Migrating from an imap/pop service to Exchange. About 95% migrated.
Hosting about 12k users

Two 2-node clusterd Exchange mailbox servers
Four load-balanced Exchange front-end servers (OWA, IMAP, POP)
250 Gb total storage

Brown has a central Active Directory
- people container is totally separate from the departmental container that has machines and groups/lists.

Two kinds of databases in an exchange information store
mapi store (available to mapi clients)
direct access by imap, pop, OWA
on the fly conversion of content when accessed by the other kind of client

Exchange public folders

Not in heavy use at Brown, but some use – e.g. for storing vacation calendars, shared contacts, shared lists, collections of project files.

Converting shared IDs into shared mailboxes with ACLs.

sizing -

DB size based on wanting to recover single database based on backup needs.
Many small databases on each server (about a dozen)

Exchange costs:
1 FTE for migration and maaintenance
- One time costs:
– migration 1.5 fte split between admin and tech duties
- license – Microsoft CAL license requred
- license: OS and Exchange sw – $11k
HW – four front end servers – $30k
HW: staff cluster – $60k
HW- Student cluster $60k
SAN storage – $70k
Provisioning changes – coincided with provisioning avehaul (automatic password creation and sync, print services, etc).

Total one-time cost: $231k

(by my math that’s about $50/user/year just for hardware, based on a four-year life cycle)

Quotas – fac/staff 100Mb quotas, students 25 Mb

Students don’t get MAPI access – pop, imap, or web client only

Have to recover an entire database to recover a single mailbox or folder.

In this room of senior technology people from 25 or so major US research universities, I count 21 Mac Powerbooks and 19 intel-based machines. The question is, are these folks leading indicators, or just outliers?