The CalDAV code is almost entirely orthogonal to the base Cyrus code so
I don't see it effecting the stability of the other services. Those
changes that were made to the base code are running at CMU so they
should be fine. That being said, if httpd is complete crap, then it
could effect the stability of the server as a whole.
I already have compile-time options in place so that httpd is only built
if --enable-caldav and/or
--enable-rss are specified.
We already have CalDAV and RSS components in bugzilla which I have been
using to remind myself of things that need to be fixed/completed.
Rebasing CalDAV on master won't be trivial, but I also don't think it
will be overly difficult. It only took me about a day to go from master
to 2.4, so I don't think the reverse will take much longer. Its mostly
just catching up with the API changes that Bron/Greg have made.
Its hard to gauge the support effort at this point until we get more
people using it. Its mostly understanding how to configure the clients,
since each one that I have used has different requirements. iCal is the
best since it has the most advanced auto-configure detection. Evolution
is pretty good at finding calendars, Lightning needs to be spoon fed.
Outlook doesn't have any native CalDAV support that I'm aware of.
On 4/15/12 2:47 PM, Jeroen van Meeuwen wrote:
On Sunday, April 15, 2012 01:18:55 PM Dave McMurtrie wrote:
Maybe we can all get together on IRC and talk about CalDAV and 2.5.
Yes, CalDAV is one of those enhancements I don't believe currently has a
ticket + blocking dependency yet, right?
Ken is very close to having the initial CalDAV implementation done. We are
attending the CalConnect InterOP session near the end of May. We were
thinking that by some time in June he will be ready for an alpha quality
release that will include all the initial features including server-side
scheduling support.
Currently his code only works for 2.4. We obviously don't want to do an
alpha release of a major new feature as part of a minor version 2.4.x
release. Ken and I discussed the possibility of doing an initial alpha
release of his code as a separate download, so you could either download
the usual cyrus-imap-2.4.14.tar.gz or
cyrus-imap-caldav-2.4.14-alpha.tar.gz. The idea would be that we would
release this alongside each minor 2.4.x release as an alpha, then
incorporate it into either 2.5 or 2.6.
Thoughts?
Plenty of thoughts, of course ;-) Let me try and put them in writing.
I'm thinking out loud with the following assumptions:
- CalDAV is here to stay -thus ends up in mainstream at some point. Perhaps a
d'oh.
- CalDAV can be enabled / disabled during compile time, in a fashion that does
not impact runtime (or runtime's stability, if you will).
- Rebasing CalDAV on top of master is major effort, and thus time, and
- Waiting longer is only going to increase that effort.
That said, I'm thinking of the following conditionals:
- Depending on how much we want in 2.5 (as opposed to postponing some of it to
2.6?), there may not be enough time for CalDAV in 2.5 - other people are
better capable of saying that's true or false, than I am.
- If CalDAV can be made to, ./configure --enable-caldav style, not impact
runtime's stability for non-CalDAV builds, merging into master before 2.5 is
the way to go. I'm fairly certain we only have to be reasonably confident
here. I'm also fairly certain that given enough pre-releases (development
snapshot releases), we can get away with unstable software fairly reasonable -
perhaps, arguably, changing the Cyrus IMAP mantra from stable-stable-stable to
release-early-release-often and maybe even "step up, or shut up".
- Once CalDAV is out there, with up to 7 billion users using it, what do we
estimate the support effort is going to be? The point being; If we can say
now, that it is going to be "too much", I suspect that also answers the
question of whether CalDAV is supposed to be in 2.5. If it's more like
"difficult to catch up with", we have a reasonable road to salvation.
I welcome the initial alpha release idea. In fact, I'd like to explore doing
such releases (as with enhancement tickets for 2.5 being released in
development snapshots) *regardless* of whether the code is based on 2.4 or
2.5. Such releases, after all, are for the sole purpose of testing and ironing
out the kinks.
I suppose there's going to need to be some time for a test suite like
Cassandane to catch up with CalDAV development as well.
A final thought is that, if we do cyrus-caldav releases, we can also create a
Cyrus CalDAV product in Bugzilla, for beyond-mainstream -those too can be
merged back. CalDAV releases could then move forward at their own pace as
well, i.e. 2.4.14.1, 2.4.14.2 releases.
Kind regards,
Jeroen van Meeuwen
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
