[Calendarserver-discuss] Free Software calendaring and groupware (in and beyond Debian)

[Paul Boddie]

On Friday 23. October 2015 15.19.11 Guido Günther wrote:
> 
> To "get started easily" the "all in one solutions" itself that are
> already packaged or on their way into Debian (e.g. sogo, zarafa) might
> be a good pick but I think that's not what you're after.

No, not really. Zarafa is on its way in, and that will be interesting to see 
when it finally arrives. I haven't kept up with SOGo, although I have read up 
a bit about it.

What I'm missing, though, is the path that people might take if they're 
already using an MTA and other things. All of these "all in one solutions" 
make choices on your behalf, which is probably great for the person building 
their own little groupware empire from scratch, but not so great for people 
who are already managing infrastructure.

> I'm not aware of someone working on integrating different parts that
> cover e.g. different areas (e.g. mail, contacts, calendar) at the moment
> to have a easy start solution. There have been some efforts on the DGMs
> though to improve on this situation (including myself working on simpler
> calendaring setup).

I guess some people might claim that you can do a lot of stuff in LDAP - I 
think FreedomBox is making substantial use of LDAP, in fact - but obviously 
beyond identities and preferences, there's actual functionality that has to be 
provided. I think this is where CalDAV servers are tempting because they can 
be bolted onto the existing infrastructure, but then they appear to require 
yet more effort to configure.

Indeed, after trying to make a "nice" way of configuring Kolab to work in a 
sensible way by default, and having seen that various components just throw 
"how to" materials at administrators, requiring them to make important policy 
decisions that need to uphold security and not break when upgrading, I can 
totally see how FreedomBox involves a lot more than just bundling a bunch of 
packages and calling the job done.

> > A bit of context here: I've been writing components that integrate with
> > MTAs to handle calendaring messages, and aside from the conventional
> > usage of such things to handle person-to-person scheduling, there's also
> > the potential for developing automated solutions for scheduling. Kolab
> > provides a daemon for this kind of thing called Wallace, and I imagine
> > other solutions do similar things.
> 
> Nice.

I'm aiming to release this very soon. I'm sure it might be described as old-
fashioned, but it just operates by adding mail handlers that understand 
calendar objects and can build scheduling information from sent and received 
events.

Initially, I thought that all I would be doing was filling in some very small 
gaps in mail client functionality with regard to calendaring, but as I've been 
filling out the support for the more exotic parts of the RFCs, I've noticed 
that various clients don't support certain things at all. For instance, unless 
it has been added recently, Lightning/Iceowl doesn't support COUNTER messages. 
And Claws doesn't support recurring events at all, as far as I can tell.

Perhaps a lot of focus has been put on Web-based clients, and perhaps I should 
look at them a bit closer to see if they implement more of the iTIP 
specification.

> > However, very few solutions actually seem to describe their architecture
> > in a way that makes it obvious how people might develop these things
> > further, especially in a way that is independent of a particular
> > solution or technology stack. I'd hoped that people had done things "the
> > Unix way" in the past and that I'd find mail-related tools that dealt
> > with calendar messages and other things, but it seems like an area where
> > everybody does their own thing.
> 
> I think you're right on that one although it would be nice to improve in
> that area.

Yes. For example, I know that the kind of mail handling my own code does must 
also be done by the "all in one solutions" because they cannot necessarily 
leave certain transactions to the client (and there's also a trend towards 
centralisation where the server is smart and doesn't want to leave it to the 
client to handle transactions), but you have to dig around in the code to find 
any trace of such functionality.

[...]

> > Which calendar client do you use, if I may ask? I've looked at Kontact,
> > Lightning/Iceowl and Claws (with calendar plugin), and they each have
> > their strengths and weaknesses. I also have some experience with
> > Roundcube's calendar plugin for Kolab, and I've seen what things like
> > Horde (with Kronolith) offer. I've even developed some Web-based
> > functionality of my own, which has been informative.
> 
> I'm using Iceowl (standalone and in Thunderbird) and syncevolution (for
> the phone).

Interesting! Another thing I wrote was an extension for Iceowl to retrieve 
Web-published free/busy data from a URL published in an LDAP database. I found 
the code to be a bit incoherent with regard to handling common kinds of data, 
with copy-paste almost the accepted way to reimplement certain tasks (a bit 
reminiscent of the Linux kernel USB support, which is another thing I got 
exposed to in the past few years), but I think there's a lot of potential for 
interesting functionality, too.

Paul