will try to answer inline On Wed, May 25, 2016 at 8:17 PM, Ankush Mishra <[email protected]> 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
