#1197 Lets find a calendar server.
Closed: Fixed None Opened 10 years ago by mmcgrath.

Lets evaluate some calendar services.


There were a few candidates.[[BR]]

  1. SOGo[[BR]]

i) Installed at http://publictest15.fedoraproject.org/SOGo [[BR]]
ii) Needs LDAP.[[BR]]
iii) Dropped.[[BR]]

  1. Bedework at [[BR]]
    i) http://www.bedework.org/

  2. Zicula at[[BR]]
    i) http://www.yourcmsnews.com/?p=224 [[BR]]
    ii) srpm at http://ke4qqq.fedorapeople.org/zikula-1.1.1-9.fc10.src.rpm

Adding John to this ticket, he'll be interested.

http://publictest15.fedoraproject.org:8080/bedework/

susmit recently got that up, it'll go up and down as we test.

Do we really need to install zicula?
We can try it out at http://demo.zikula.org/

In order to test the plugin:

http://community.zikula.org/module-Extensions-display-ot-component-componentid-7.htm

we'll have to. Also we need to do the installation to get a view of maintenance and setup costs.

Zikula is done at

http://publictest15.fedoraproject.org/zikula/

username/passwd: testuser/testuser.
For admin access, ask mmcgrath.

ok...I was installing bedework 3.5 for ease of deployment.
But it needs sun java..policy does not allow that.
Dropping it.

BTW, the rpm by ke4qqq wanted php 5.2 where we had only php 5.1 on our EL server.
So I installed from source (well it's not source)

Citadel at http://www.citadel.org/doku.php?id=start also looks good and FOSS.
Give it a go?

CITADEL is up and running at http://publictest15.fedoraproject.org:2000/[[BR]]
login as testuser/testuser. For admin access, ask mmcgrath.

Details: runs on tcp/504, Runs as user:citadel [[BR]]

Supports openid [[BR]]

released under GPLv3[[BR]]

Supports text sms

I was trying to install bongo[1] : installation guide[2] says "Bongo is currently alpha-quality software. It is under active development and is not yet ready for production servers. However, we encourage you to try it out in a test environment and let us know what you think!"
[1] http://bongo-project.org/
[2] http://bongo-project.org/Installation

davical rscds.sourceforge.net/ is a server supporting caldev.
rscds.sourceforge.net/

But it does not support web based fronend!!! :O

"There is no ability to view and / or maintain calendars or events from within this administrative interface. To do that you will need to use a CalDAV capable calendaring application such as Evolution, Sunbird, Thunderbird (with the Lightning extension) or Mulberry."

It is available at http://publictest15.fedoraproject.org/davical/

username/passwd: testuser/testuser

Another three servers are up

  1. PHP iCalendar (http://phpicalendar.net/): PHP-based iCAL v.2.0 file
    parser / displayer. One sends/retrieves the files via WebDAV: PHP
    iCalendar itself is view-only.
    http://publictest15.fedoraproject.org/phpical/phpicalendar/

  2. Webcalender (webcalendar.sourceforge.net/) :
    http://publictest15.fedoraproject.org/webcalender/

  3. http://publictest15.fedoraproject.org/phpgroupware/

Username/passwd is same as usual.

I missed something.

The required functionalities can easily be implemented with Calenderserver[1] as backend and as front-end http://trac.calendarserver.org/wiki/Chandler

I shall set it up soon and let you know.

chandler needs python 2.5.
Publictest15 running el5 which provides 2.4.
Opened a ticket. (ticket #1299)

Chandler need a 32 bit VM to build properly.
Build attempts in non-debian, non-32 bit machines were messy and unsuccessful.

That might be a big blocker on using it in Fedora Infrastructure, since the calender application would eventually need to get into Fedora.

I have not checked it very carefully.
Once I have a 32 bit machine, I can try and comfirm.
Having a 32 bit VM going to be a big problem?

I was referring to the non-Debian part :-) I've personally been having a lot of trouble building a 32 bit Fedora on our RHEL hosts (kernel panics), but I'll ask around for some help with that and possibly file some bugs for this later today.

As a side note, there is a kernel update for the machine I've been trying on (ibiblio1). That might be something to look at as well.

Replying to [ticket:1197 mmcgrath]:

Lets evaluate some calendar services.

Is it possible to have a event calendaring service that does the following:

  • uses the FAS login to provide a form that requests the user to input the following:
    -- link to the Fedora Events page
    -- Date, Time and Venue of the Event
    -- Name of the event

The following parts can then be validated:

  • whether it is a valid request from a Fedora Ambassador (checking up from the approved groups)
  • whether there is a Fedora Events page link

Based on that it is to be published on the calendar

However, it might make sense to have a Category:Events and, make the Events page a Category page listing

I believe that a Fedora solution should support open standards like [http://www.ietf.org/rfc/rfc4791.txt RFC 4791] ("[http://en.wikipedia.org/wiki/CalDAV CalDAV]"). This would probably limit the choices to maybe Darwin Calendar Server, bedework and Cosmo. I may be missing some, and someone may add a couple more.

What do others think? Is CalDAV a sane requirement for Fedora's calendaring?

Just for thoughts, a user wrote a 700 lines javascript & html web frontend for CalDAV servers.

http://www.local-guru.net/blog/2009/03/29/javascript-caldav-frontend

I'm not saying to use that particular code, but that having a server that speaks a standard helps both users and developers.

What are the requirements and use cases driving our desire/need for a "calendaring solution?" Without those how will we know we are choosing the right right solution to address right right problems?

Well, requirements are[[BR]]

  1. Need to be completely free. No Sun Java.[[BR]]

  2. Push/Pull/Update from handheld devices. (Using which protocol is not much of a concern).[[BR]]

  3. Free/Busy type calender.[[BR]]

  4. Update/View in browser.

What kind of events are we trying to track?
* Project Meetings
* Events worldwide
* Project schedule
* ?

Another possibility if we are just looking for track events is: http://calagator.org/

Replying to [comment:29 susmit]:

  1. Need to be completely free. No Sun Java.[[BR]]

How difficult is it to get bedework working with OpenJDK? It is said to only miss SNMP.

  1. Push/Pull/Update from handheld devices. (Using which protocol is not much of a concern).[[BR]]

Why not? AFAIK there are quite a few different protocols depending on the brand. If support for mobile devices is a requirement then it would have to come with several protocols.

Is multisync/opensync something to consider?

As requirements I'd also like to add

  • ability to use from desktop applications (like evolution and friends)
  • based on open standards

another interesting candidate--heard about it at OSCON last year. Just remembered it. http://freshmeat.net/projects/obm

This would be very handy for the Fedora IRC Classroom as well... so we could schedule classes and people could subscribe or note when they are being held.

I have installed obm here

https://publictest15.fedoraproject.org/

passwd:test/test and admin1/

However, the calender is not up yet. I have to visit the mailing list and find out
1. if it can be configured without ldap.
2. Which module is needed for calender

yeah. It's now working.

test it at:

domain: test
user name: admin_test/susmit

Please don't break it with admin passwd. :)

Susmit, come see me in #fedora-admin when you get a second. I'd like to see zarafa on one of the pt servers as well. Here are the bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=498194

https://bugzilla.redhat.com/show_bug.cgi?id=498195

Replying to [comment:38 mmcgrath]:

Susmit, come see me in #fedora-admin when you get a second.

Sure.

I'd like to see zarafa on one of the pt servers as well. Here are the bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=498194

https://bugzilla.redhat.com/show_bug.cgi?id=498195

You have it here:
http://publictest15.fedoraproject.org/webaccess/
admin/zarafa_admin

Note to myself:
zarafa-admin -c $username -p $pass -e $mail -f $fullname -a 0|1

Has anyone taken a look at zarafa?

I've just come across another candidate: egroupware - http://www.egroupware.org/ . It's implemented in PHP (typically run on top of Apache) and has a quite nice web interface (by the looks of the demo, anyway) and CalDAV support for the calendar module. It seems slightly more community-oriented and slightly less concerned with being a slavish ActiveSync clone than Zarafa.

I'm probably going to implement it on my own network (running on Mandriva), so I'll try and remember to report back on how that goes.

Well...it works!

http://www.happyassassin.net/extras/egroupware_caldav_it_works.png

egroupware's web interface on the right showing the test appointment I set up, evolution on the left showing the same appointment: it's accessing the calendar from my personal egroupware server, via CalDAV (see the left hand pane).

It seems like a pretty impressive little beastie, too. I managed to kill it by somewhat inadvisedly trying to use its webmail support with my fairly underpowered mail server's gigantic IMAP mail boxes, without using the imapproxy instance I have set up on the mail server. I think
it timed out on something and left its MySQL database in a broken state. But that's the only problem I had. I haven't gone beyond setting up the test calendar appointment and verifying Evo could connect to it, really, but I'll stress it a bit more tomorrow by trying to get SyncML working, sticking my real calendar in it, and trying contacts as well.

The server I'm using runs Mandriva; I've updated Mandriva's egroupware packages for this purpose. It'd be fairly trivial to convert the packages to Fedora. Upstream actually provides Fedora packages, but at a glance they're not terribly clean. I haven't checked whether there are
any private copies of what ought to be shared resources in egroupware yet, really, but at a glance it doesn't involve any hideous packaging nightmares; it's all just PHP, and it seems to use shared resources where appropriate (it uses quite a lot of php-pear stuff).

Do poke me on IRC if you have any questions. Duplicated from the list.

Replying to [comment:43 adamwill]:

(...) It seems slightly more community-oriented and slightly less concerned with being a slavish !ActiveSync clone than Zarafa.

Euh... these are two false statements ;-)

  • Zarafa is very much aware of the community and has been doing this Open Source thing for just about a year now (they've come a long way)
  • Z-Push is an !ActiveSync implementation on top of Zarafa.

I won't able to persue this anymore.
If someone else is interested, please take it up,
Thanks.

Is there anyone working on it? Otherwise I'd be willing to give it a go.

Has any consensus been reached about what to discard and what to keep? Personally I'd tag caldav support as a must.

I think we've generally agreed that zarafa is the way to go but we've not actually done the work on a pt server to get it setup, integrated with FAS, etc. If you're volunteering I can get you in sysadmin-test and hand over a pt server and we can see how it goes from there?

susmit did setup zarafa on a pt server according to comments [comment:39 39], [comment:40 40] and [comment:42 42], but it looks like no one tested it, or, if someone did, he did not comment in this bug report.

Also I checked on the feature set of zarafa and among others I'm missing SyncML support. E.g. syncing against zarafa seems to be only possible using proprietary protocols on the handheld side (!ActiveSync).

I think we need to think on a larger scale: Calendaring is usually part of a a quartet of the following components:

  • calendar
  • addressbook
  • todo
  • memo

Sometimes calendar and todo are mangled together.

A Fedora solution should be able to manage these using open standards and protocols. This means for calendar CalDAV and for addressbook CardDAV or at least vcard support. The syncing should at least support SyncML.

Zarafa's docs testify CalDAV support, but neither CardDAV, nor SyncML are supported. CardDAV being in development and still a draft is a nice-to-have feature, but the missing SyncML is hurting.

I also looked at Adam's suggestion and eGroupWare seems to have all that and more. It seems to lack ActiveSync support, but given SyncML vs !ActiveSync Fedora will always opt for the former. Should !ActiveSync be a must-have-feature then there is also Tine 2.0 which is a fork of eGroupWare with !ActiveSync support.

Is there any reason not to test eGroupWare/Tine 2.0 instead of zarafa?

It also depends on the whether the structures of FAS can be mapped to addressbooks in whether solution is a candidate.

Just to add that: ActiveSync is open documented by Microsoft; specifications can be read online. As CardDAV isn't ready or done right now, Zarafa didn't implement it so far. In general, Zarafa implements things, that have established themself, and not because it's yet another standard that nearly nobody actively uses. By the way, from the business perspective (where Zarafa comes from), ActiveSync is more common than SyncML (just have a look which mobile devices support ActiveSync out of the box and compare with SyncML support).

But yes, evaluating other software for Fedora's needs is generally a good idea.

Replying to [comment:51 robert]:

Just to add that: !ActiveSync is open documented by Microsoft; specifications can be read online.

Openchange did have to reverse engineer it for whatever reason. Maybe due to MS's move from client licensing to patent licensing?

Is !ActiveSync even patent-free enough for Fedora to host support for it on its servers? I think I saw a couple of "Outlook/Exchange connector" reviews to not make it into Fedora due to possible patent issues. If it can't make it into the repo, then how can we host it on Fedora services?

As CardDAV isn't ready or done right now, Zarafa didn't implement it so far. In general, Zarafa implements things, that have established themself, and not because it's yet another standard that nearly nobody actively uses.

I wouldn't label it an unestablished-yet-another-standard when Apple, KDE and even Zimbra and SoGO already ship support for it. It is definitely in use, and the ratification process is far beyond any possible changes to the specs. Given the iOS4 support for it I think it will get quite more popular very soon.

But indeed I wouldn't call (and haven't called) CardDAV a mandatory component of a Fedora solution, just that having something that caters for the near future is a good thing if all other things are equal. SyncML support is more the issue here, as it is established, used on many devices from almost all vendors and an open, free and stable specification for data exchange between mobiles.

By the way, from the business perspective (where Zarafa comes from), !ActiveSync is more common than SyncML (just have a look which mobile devices support !ActiveSync out of the box and compare with SyncML support).

Well, if that is an argument, then from a Business POV Linux and Fedora would have never emerged, and we would be running Outlook and Windows Mobile. ;)

But I understand what you are saying, we'd like to serve as many users as possible. The question is whether the typical Fedora developer, that wants to sync his mobiles against Fedora's calendar/contacts etc., lives within an Exchange Server controlled environment or more likely being the one running his company's Groupware servers himself? I also think that low cost phones only have SyncML support (maybe there are license fees for !ActiveSync on mobiles?).

Fedora is about real open standards and a patent free zone, so I feel when it comes to !ActiveSync vs SyncML/CalDAV/CardDAV then the latter should take priority.

Why was SOGo dropped? It doesn't really need LDAP (as was stated in the first comment), but should happily run of a pure database of users. Having LDAP is of course very nice..

It does seem to support all major protocolls for sharing calendar data (email, caldav, syncml, activeSync)..

Well, at the very least it would need to be packaged up. ;)

Keep in mind, that ActiveSync is patented in the US. I don't think Fedora Legal will allow us to run an ActiveSync serverside component, if we even can't ship such a software as part of Fedora?

this is not a calendar server but is a GPL licensed version of whenisgood.net - it helps people figure out the best time for a meeting:

https://github.com/sander/pleft/tree/master/pleft

It doesn't have caldav support, though.

Login to comment on this ticket.

Metadata