You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by Maxim Solodovnik <so...@gmail.com> on 2016/05/26 06:19:49 UTC
Re: With regard to CalDAV4j and a sort of Status Update
will try to answer inline
On Wed, May 25, 2016 at 8:17 PM, Ankush Mishra <an...@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