Re: [vox-tech] CalDAV
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] CalDAV
> 1. Rapid standards churn. iCAL, xCal, iTIP, iMIP, vCalendar, vCard,
> BEEP, CAP, WebDAV, CalDAV.... Seems like CalDAV has become the
> surviving commodity standard, but those of us who watched the standards
> squabble over the yeard got a bit lost in all of the alphabet soup, and
> one suspects that a common reaction was 'Wake me up when all of this
> gets sorted out.'
> 2. Lack of enthusiasm for Java. Bedework, like UW Calendar before it,
> seems like a huge amount of Java infrastructure (servlets, directory
> services, a lot more) and a back-end database for a fairly basic set of
> scheduling functions that might possibly be achievable without so
> much... stuff.
> Seems to be a common syndrome, e.g., Chandler Server (Cosmo). And the
> non-Java alternatives are pretty heavy engineering, too.
A bit further to that, speaking on a personal level: I keep hoping to
find a moderately well debugged package, coded in C, or Python, or Perl,
or Ruby, that I can just drop into my modest Apache2/Exim server without
having to rearchitect everything, that would allow me to publish
calendars and do free/busy event transactions that integrate with
existing SMTP. I would expect to just enable WebDAV access support in
my Apache2 setup, drop in the calendar thing, and have it Just Work
without more fussing around.
And that's just not happening. Everyone wants to make a groupware suite
that does absolutely everything, wants to take over the world, and has
incredibly picky and incredibly extensive requirements. I cannot just
drop Bedework, or Bongo Project, or Cosmo, or Dingo Calendar Server, or
ScalableOGo, or EGroupware into my old PIII server and have any of
those play well with my existing server configuration. Almost all
insist on a specific back-end database, and many want LDAP-based
_Maybe_ Apple Calendar and Contacts Server will do a simple drop-in.
Or Radicale. Or SabreDAV.
I had hopes, some years ago, for Hula Project, which Novell killed off
in the process of trying to turn it over to a third-party developer
group. As the project was dying, Bongo Project was created as a fork
from it. Here we are in 2011, and it's still a beta, but one of the
cheering things about its Hula predecessor is that it did _not_ attempt
to take over the world. Because they listened to Jamie Zawinski, who
knows more than most people about how corporate overengineering can
kill open source projects right in the design phase. Here's Jamie
telling the story, and I do recommend spending the time reading it:
Anyway, _maybe_ Bongo Project is an answer. Except, er... Mono?
Really? Oh yeah, that's that Novell factor at work. And there are only
unofficial packages for most distributions, because nobody outside
Novell ever was enthusiastic for it. E.g.:
And look at all that stuff. Might as well be J2EE.
vox-tech mailing list