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

[Guido Günther]

Hi Paul,
On Fri, Oct 23, 2015 at 06:27:17PM +0200, Paul Boddie wrote:
> 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 fully agree here. It would be nice to have better integration for
things like calypso/radicale/calendarserver without lots of effort + web
frontends that can cover these things too. And then there's interacting
with invitations in your mail stream...

> 
> > 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.

calendarserver has some support for this but I've not looked at it,
maybe the maintainer can chime in?

> 
> > > 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.

Cheers,
 -- Guido