openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Solodovnik <solomax...@gmail.com>
Subject Re: GSoC: Discussion on Libraries to use for CalDAV
Date Thu, 28 Apr 2016 04:04:07 GMT
If I were you I would use https://github.com/caldav4j/caldav4j :)
You always can fork it fix something and propose PR to the original repo :)
I would update libraries they are depend on :)
In case their community is not active at all I can publish necessary
artifacts into our own repo: https://bintray.com/openmeetings/maven/

On Thu, Apr 28, 2016 at 6:56 AM, Ankush Mishra <ankushmishra9@gmail.com>
wrote:

> Looks like I forgot to CC, again. Would love to hear what you all think on
> this.
>
> Ankush
> ---------- Forwarded message ----------
> From: "Ankush Mishra" <ankushmishra9@gmail.com>
> Date: 27 Apr 2016 19:34
> Subject: GSoC: Discussion on Libraries to use for CalDAV
> To: "dev" <dev@openmeetings.apache.org>
> Cc:
>
> Here's the current list of CalDAV library implementations in JAVA:
>
>  - iCal4j (which is used in the project already for handling ics):
>    This is already used to send out event invites through email. Just that
> this might still be used for handling CalDAV as the calendar data is still
> made up of iCal.
>     There exists an iCal4j-connector which from their page, also,
> implements the CalDAV using jackrabbit-webdav library. But it's development
> seems to have stopped since 2013.
>
>  - CalDAV4j ( https://github.com/caldav4j/caldav4j ):
>
>    From their Project Page:
>    CalDAV4j is a protocol library that extends the Slide project's WebDAV
> client library (which itself is an extension of the Apache's HttpClient
> library) to allow high level manipulation of CalDAV calendar collections as
> well as lower level CalDAV protocol interactions. This project uses iCal4j
> for iCalendar processing.
>
>    This project is promising and their library is stable to use. But from
> their googlecode commits it was last commited on Nov 2013, though since
> moving to GitHub, it still hasn't had much happen.
>
>    One thing I have noticed it's still missing the CalDAV ACL's, things
> like "PRINCIPAL" query haven't been implemented. I'm also not sure of it's
> status of development or it's integration to the JackRabbit sources, but
> from digging up it's history I notice that the Open Source Applications
> Foundation (OSAF) is now defunct, and thus, it might seem like the project
> is at a halt. There also seem to be issues with jackrabbit-webdav
> integeration, it still seems to be using Apache Slide as the WebDAV
> library, atleast in the master branches, though there is a branch on the
> Google Code for caldav4j-webdav using the jackrabbit-webdav library(
> https://caldav4j.googlecode.com/svn/branches/caldav4j-jackrabbit/).
>
>
>  - JackRabbit-WebDAV (
> https://jackrabbit.apache.org/jcr/components/jackrabbit-webdav-library.html)
> :
>    Taken from their project page:
>    This is the WebDAV Library component of the Apache Jackrabbit project.
> This component provides interfaces and common utility classes used for
> building a WebDAV server or client.
>
>    It supports DAV 1, 2, DeltaV, Ordering, Access Control, Search, Bind.
>
>
> In the end both CalDAV4j and Jackrabbit-webdav, can be used. It'd be
> preferrable to use CalDAV4j, which directly implements CalDAV protocol but
> extends Apache Slide WebDAV protocol library. The main problem with
> caldav4j is that Apache abandoned Slide in 2007 and therefore it is based
> on a deprecated library (now Apache advises to consider Jackrabbit project
> instead). And Jackrabbit-webdav implements only WebDAV specific code. Some
> operations will be very familiar if you already have experience with HTTP
> services (GET, PUT and DELETE), but many are added too (MKCOL, MKCALENDAR).
>
>
> Thus comes the dilemma of which library to use, perhaps at some part even
> the CalDAV4j, could fail, and it would be easier to use jackrabbit-webdav
> at places to implement parts which don't already exist.
>
> In the end, I'm still not certain of which library to use.
>
> Ankush
>



-- 
WBR
Maxim aka solomax

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message