Mailing-List: contact dev-help@openmeetings.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openmeetings.apache.org
MIME-Version: 1.0
In-Reply-To: <5745B3F7.6020604@gmail.com>
References: <5745B3F7.6020604@gmail.com>
Date: Thu, 26 May 2016 12:19:49 +0600
Message-ID: <CAJmbs8gP1ijNfVrNrE4jLaKfJ6_VZXBRij6dY_H9dhvAvT-pHA@mail.gmail.com>
Subject: Re: With regard to CalDAV4j and a sort of Status Update
From: Maxim Solodovnik <solomax666@gmail.com>
To: Ankush Mishra <ankushmishra9@gmail.com>
Cc: Sebastian Wagner <seba.wagner@gmail.com>, dev <dev@openmeetings.apache.org>
Content-Type: multipart/alternative; boundary=001a1133753807f4bf0533b8c723
archived-at: Thu, 26 May 2016 06:19:56 -0000

--001a1133753807f4bf0533b8c723
Content-Type: text/plain; charset=UTF-8

will try to answer inline

On Wed, May 25, 2016 at 8:17 PM, Ankush Mishra <ankushmishra9@gmail.com>
wrote:

> I have to bring this to the front, as stated in my previous report,
> atleast 80% - 90% of the work is done with respect to the migration.
> Problem, as I stated earlier was that Compatibility with respect to the
> previous library had to be carried out. The thing is, in this part of
> migration, I can't be certain of how long will the work take to complete,
> because of the design issues that might arise, like changing whole response
> classes and so on, might have to be looked into again. Like for example,
> right now I could directly use the *jackrabbit* response classes, but it
> turns out that CalDAV4j has it's own response classes which may or may not
> be compatible with the *jackrabbit* ones, and it can't simply be
> extended, as noted here.
> <https://github.com/caldav4j/caldav4j/issues/59#issuecomment-221483973>
> [1]
>
> So, what I'd like to propose is that I work on the migration of the
> library in the background, while using the older version of the library.
> Until, the newer version seems stable enough to be used.
>

OK with me
I would propose the same


>
> Other than that, there are some things regarding the openmeetings-db,
> AppointmentDTO class specifically. So, I have been mostly researching and
> working on the Initialization of Events, and syncing. There are two
> specific things which I need information about. If I'm going to implement
> CalDAV, then:
>
>    - I'd need to implement a sort of *Calendar Manager* of sorts.
>    Something in the lines of Google Calendar, where the default calendar every
>    user has is the *OM Calendar* which is a sort of public calendar, and
>    the rest of the calendars could either be a local calendar on the OM DB or
>    a CalDAV server. This would allow the creation/read/update/write to
>    calendars. This would require a whole new Entity Class and the rest of the
>    data associated with these calendars, per user. But this feels a bit heavy,
>    when we have multiple users. For the Calendars, the specifics, I still have
>    to look into.
>
> I can add OmCalendar entity and all DB/display processing , but I need to
know what this entity should store ....
Currently I see only calendar URL to be stored (to be able to display
external calendar in OM)
Any other fields?

>
>    -
>    - AppointmentDTO specific, after debating on whether I should keep the
>    calendar data as ical or Appointment. I believe It'd be a better option to
>    stick with Appointment, since, it already exists. Has most if not all the
>    data.
>
> Specifically (the only one I know of), normally in CalDAV the *id* or *entity
> tag* as it's called, is a string, which uniquely identifies the calendar
> event, other than the *location*. There could be multiple ways of
> implementing a new Appointment which support both the local and on network
> events.
>
>
>    - Change the *id* to string. And treat all events with id's which come
>       as String.
>       - Along with *id* as String, have a boolean value specifying
>       whether it's on the CalDAV Server or on the OM Server. Treat strings as
>       long, when it's OM Server and as normal strings when a CalDAV.
>       - Set *icalid* for the CalDAV events instead of *uid*, just that it
>       might conflict with the InvitationManager, but not entirely sure.
>
> I believe icalid should be used as CalDAV id, currently it's autogenerated
something and, I believe, it can be changed without any affect on something
else

>
>
> Any help or comments is appreciated, on the direction, I am taking.
> [1] https://github.com/caldav4j/caldav4j/issues/59#issuecomment-221483973
>
> --
> Ankush Mishra
>
>


-- 
WBR
Maxim aka solomax

--001a1133753807f4bf0533b8c723--