[Calendarserver-discuss] Free Software calendaring and groupware (in and beyond Debian)
agx at sigxcpu.org
Fri Nov 6 16:41:40 UTC 2015
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
> 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
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.
More information about the Calendarserver-discuss