On 24/02/13 13:24, Ed W wrote:
Hi
The CardDAV support is being implemented as a new and independent plugin as the Kolab addressbook is completely different and does not support backend 'drivers'.
Our CalDAV implementation is using the SabreDAV (http://code.google.com/p/sabredav/) and the sabre-vobject (https://github.com/evert/sabre-vobject) Libraries.
In both cases our target CalDAV/CardDAV server is SOGo
This sounds very cool. Kolab seems like the best implemented PHP calendar/contacts/Notes frontend right now.
Yes, the Kolab team have done a great job on this plugin.
However, SOGo already has an excellent web interface which does almost everything Kolab does - I'm slightly curious as to why you don't use it?!
We have been using Roundcube for longer than SOGo. We have an investment into Roundcube in the way of plugins etc. The SOGo interface, although fully functional, does not have the same level of polish that Roundcube has. Asking people to swap from the Roundcube to the SOGo UI for using groupware technology is not something we want to do.
I would not want to presume or dictate anything for SOGo, however if the SOGo team would have an alternative end-user UI and does not need to spend time and effort maintaining their own webmail/addressbook/calendar product. It would be possible for them to spend more time on the backend core and possibly a management UI that would be more beneficial to the community as a whole
My interest is that I find roundcube slightly more responsive and also simpler to deploy. It's also easier to modify and extend. However, whilst I'm a bit scared by a lot of the code, OwnCloud is looking like my best partner and it's basically a wrapper around sabredav. (I like the DAV filesharing piece for our solution)
We evaluated OwnCloud a while back. We were not so impressed and decided not to look at it further. With regards to DAV file-sharing, we had a AjaXplorer system deployed before OwnCloud existed.
As such my initial thought for integration with roundcube was to talk directly to the backend databases. Kolab expects all the fields to be in separate columns, but owncloud simple stores the original vcard/ical field as a blob and it requires parsing. Interested in the design you have gone for - my (naive) thoughts were just to add an ical/vcard parser and connect the DB tables directly - this does require some duplication of business logic though
What is your basic design? Are you connecting directly to DAV? With a local cache? Or directly talking to the backend db structure?
As stated, we are talking CalDAV and CardDAV. We are working from the RFCs as far as they are implemented in the SOGo backend.
There is no dependency on the backend implementation, which for SOGo could be MySQL, PostgreSQL, Oracle or LDAP and for other servers could be anything. Data is communicated via HTTP requests like PROPFIND from/to URLs like "/principals/" and "/.well-known/". Data is read, parsed and written as standard iCalendar/vCalendar and vCard objects.
There is no client side caching implemented as of now. As the Kolab plugin assists in only requesting the data that is to be displayed the requests are relatively small. As the server supplies an ETAG for the calendar as a whole, it should be possible, without too much effort, to cache the data without risk of using stale information.
Regards,
Chris
Thanks
Ed W _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev