Chandler's Network Architecture: Priorities Change.
We've changed our priorities for the network architecture we will use
to support sharing and collaboration in Chandler. If you follow OSAF's
work here or here, this won't come as a surprise, but as it's a pretty
significant shift it's worthy of elaboration and broader discussion.
For small groups, the use of an Microsoft Exchange server to support
group calendaring has
always been burdensome, but it has been the best available (or least
bad) choice in many cases. Exchange is designed to be deployed and
supported in medium to large enterprises with dedicated IT personnel
administering it. The motivation for Chandler came in part as I saw my
wife's small consulting firm struggle with the use of Outlook and
Exchange to support critical scheduling functions. I surmised that a
serverless (or server optional) architecture could be used to
coordinate calendars for small groups, and that became a cornerstone of
the Chandler vision. My supposition wasn't based on actual experience
with peer-to-peer approaches as much as an intuition, which turned out
to be less than fully appropriate.
The long and short of it is that initially Chandler users will share
collections of items such as calendars with each other via a WebDAV
server. Apple uses a WebDAV-based server for its proprietary .Mac
service. Lisa Dusseault, who manages the development group working on
WebDAV here, is also a long-time IETF participant and author of a
WebDAV book.
Initially, and for the first wave of bleeding edge Chandler
adopters, OSAF will be hosting servers itself. From an end-user point
of view, the goal is to make sharing data painless and transparent. We
are working on a product plan for an open source WebDAV-based server
which can be freely deployed and which will become a fundamental part
of our offerings. More on this as it develops.
This server will evolve into the server contemplated for the Westwood
release of Chandler, the one for higher education. One of the benefits
of the new plan is that we have a more direct path to bringing Westwood
into existence.
We are also looking at incorporating the server into the client
software as an additional option. Assuming we can do this, then those
Chandler users who do not want any dependence on an external server can
share data with other users directly. There will likely be some
limitations to this approach, as the client will have to be online in
order to perform this function.
True peer-to-peer coordination without this and other limitations is
something which I ruefully understand to be a difficult (some would say
unsolved) problem. If you have a lot people all trying to coordinate
and there is no central “source of truth”, when there is a partial loss
of connectivity (say it splits into two subnets each of which is fully
connected within itself, but which are isolated from each other) it is
a challenge to put Humpty Dumpty back together again and make sure
everyone has the most current version of everything. While achieving
this is still very much in the long-term Chandler vision, our emphasis
on not trying to solve research problems and even more on making
useable sooner rather than later (our “dog food” approach) made the
choice clear, if painful.
It has also occurred to me there may be another overlooked
opportunity here. I think I've unfairly maligned servers in the past.
It's not the server I dislike, it's the idea that as an end user I am
disempowered if the work I want to do depends on the administration of
a piece of software I don't control, can't get access to, and plays by
a different set of rules. The PC-era pioneer in me says, “get rid of
it”. Another approach might be, “tame it and make it serve me”.
Electricity comes out of the plug in the wall reliably (in the
developed nations). Landline telephones have reliable dial tone. Why
can't we have utility-level connectivity for user data? And why can't
it be open source? This is a big, ambitious vision, and it's not just
about servers per se, but operational reliability as an overall system
function (think Google with its hundred thousand servers) but maybe
there's something here. More on this later too.
A learning: We wound up focusing on the client software first, not
the network architecture. Having had my formative software design
experiences in the era of stand-alone PC's, it was easy to repeat the
pattern of paying more attention to what is going on on the local
machine than to what is happening across the network. While the
repository is network-aware, and, in fact, very early versions of
Chandler supported a simple form of accessing items from a remote
repository, I didn't fully appreciate until this year the importance of
considering issues of network availability, reliability, and
performance as first-rate issues in and of themselves. You're never too
old to learn (or to admit mistakes). [Mitch Kapor's Weblog]