Lets evaluate some calendar services.
There were a few candidates.[[BR]]
i) Installed at http://publictest15.fedoraproject.org/SOGo [[BR]] ii) Needs LDAP.[[BR]] iii) Dropped.[[BR]]
Bedework at [[BR]] i) http://www.bedework.org/
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
http://community.zikula.org/module-Extensions-display-ot-component-componentid-7.htm
That one looks worth.
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:
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
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/
Webcalender (webcalendar.sourceforge.net/) : http://publictest15.fedoraproject.org/webcalender/
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.
Could we try http://chandlerproject.org/ too?
chandler needs python 2.5. Publictest15 running el5 which provides 2.4. Opened a ticket. (ticket #1299)
It has also been recommended to look at - http://trac.calendarserver.org/
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]:
Is it possible to have a event calendaring service that does the following:
The following parts can then be validated:
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]]
Need to be completely free. No Sun Java.[[BR]]
Push/Pull/Update from handheld devices. (Using which protocol is not much of a concern).[[BR]]
Free/Busy type calender.[[BR]]
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]:
How difficult is it to get bedework working with OpenJDK? It is said to only miss SNMP.
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
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
I'd like to see zarafa on one of the pt servers as well. Here are the bugs:
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
zarafa is up at pt16.
http://publictest16.fedoraproject.org/webaccess/index.php login: admin/admin
ical gateway is available at: http://publictest16.fedoraproject.org:8080/ical/$username/calendar/
Has anyone taken a look at zarafa?
caldav gateway at is
http://publictest16.fedoraproject.org:8080/caldav/{$username}/calendar/
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 ;-)
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:
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
Done. We have fedocal now.
https://apps.fedoraproject.org/calendar/fedora-meeting/
It doesn't have caldav support, though.
Login to comment on this ticket.