[WIP] Introduce public calendar api #11461

DeepDiver1975 · 2014-10-07T14:38:25Z

We need a public api in ownCloud core to access available calendars.

The basic design of the api follows the contacts manager approach which is in place for quite some time now.

There are basically 3 pieces involved:

the manager - holding all calendars
the calendar - holding events and tasks
the event/task

Please review the api design! THX

@karlitschek @MorrisJobke @georgehrke @Raydiation @PVince81 @schiesbn @butonic THX

georgehrke · 2014-10-07T14:52:26Z

lib/public/calendar/icalendar.php

+		 * 		'from' 	: defines the starting point in time for the query
+		 * 		'to'	: defines the end
+		 *
+		 * @return array of events/tasks which are arrays of key-value-pairs


events/journals/tasks

When using recurrenceIds one UID might contain multiple VEvent blocks. This might cause problems when using a simple key-value pair structure

I see - can you please post some sample data? Let's see if we find an nice abstraction - THX

https://gist.github.com/georgehrke/fc606d87bfbaf5d89dfe

THX - so the true unique id is a combination of UID and RECURRENCE-ID ??

the unique id used by caldav is the uri. In most cases the uri equals the uid, but that's not always the case. The caldav standard says that all objects with the same uid have to be stored in the same resource. So the example I posted would be stored in one single db row.

okay - we better mimic the behavior in this case - THX

georgehrke · 2014-10-11T08:38:49Z

lib/public/calendar/imanager.php

+		 * @param \OCP\Calendar\ICalendar $calendar
+		 * @return void
+		 */
+		function registerCalendar(\OCP\Calendar\ICalendar $calendar);


maybe \OCP\ICalendar, it's also \OCP\IAddressBook, not \OCP\Contacts\IAddressBook

I'm aware of this inconsistency ... let me fix this

PVince81 · 2014-10-31T16:21:16Z

Would it be better if in the future apps are able to register generic managers ?
So far we always need to add specific interfaces in core for calendar, contacts, etc.

If we had something like registerService(serviceType, myServiceProvider);, any calendar app could register calendar services. But now I realize that the app wouldn't have any way to enforce the interface as it is done here.

Hmmmm... maybe something to be thought about separately.

DeepDiver1975 · 2014-11-03T09:35:30Z

Would it be better if in the future apps are able to register generic managers ?
So far we always need to add specific interfaces in core for calendar, contacts, etc.

Well - the basic idea if to nail down the 'protocol' of interapp communication within core.
Only if the interfaces are maintained in core we can ensure that the api is stable and will continue to work in the future.

As an example: have a look at the tasks app as of today - it simply reuses classes of the calendar app. This works as long as there are no changes in that specific calendar classes.
But there is a rewrite of the calendar app in progress - are the devs aware of which classes are used by any other app? And how? I'm pretty sure the calendar rewrite will break the tasks app.

And this is a very simple scenario as we know all devs and apps involved - but in a larger scope this will not work.

We need these php interface based api approach to ensure proper operations between apps. I see no other possibility.

scrutinizer-notifier · 2014-12-15T10:01:54Z

The inspection completed: 5 new issues, 18 updated code elements

DeepDiver1975 · 2014-12-15T13:24:04Z

@georgehrke @PVince81 @MorrisJobke please review

georgehrke · 2014-12-15T13:39:14Z

Is the $pattern parameter for search supposed to be a regular expression?
One problem I remember with the contacts api was that I wasn't able to search for all contacts with birthday information. (searching for birthdays with pattern "*" returned an empty array)

I can imagine similar problems here, e.g. when the maps app wants to search for all events with Location or GEO in the next 30 days.

DeepDiver1975 · 2014-12-15T13:45:21Z

lib/public/calendar/imanager.php

+	interface IManager {
+
+		/**
+		 * @param string $pattern which should match within the $searchProperties


@georgehrke the pattern would be a simple text to be searched for - no regex or something

Yep, needs better docs what actually should be passed in and an example maybe

DeepDiver1975 · 2014-12-15T13:48:04Z

One problem I remember with the contacts api was that I wasn't able to search for all contacts with birthday information. (searching for birthdays with pattern "*" returned an empty array)

Did you intend to search for all contacts who have a birthday defined or for those within a given time frame?

Regarding the general design - from my pov the contacts app should register a 'Birthday Calendar' to be consumed by any app being interested.

MorrisJobke · 2014-12-15T13:48:24Z

I'm fine with that 👍

DeepDiver1975 · 2014-12-15T13:49:19Z

I can imagine similar problems here, e.g. when the maps app wants to search for all events with Location or GEO in the next 30 days.

nice usage scenario - this is where we have to enhance the $options - just like the already defined from and to options (which are basically just an idea for now)

georgehrke · 2014-12-15T13:58:03Z

Did you intend to search for all contacts who have a birthday defined or for those within a given time frame?

My intention was to search for all contacts with a birthday defined.

DeepDiver1975 · 2014-12-15T13:59:46Z

My intention was to search for all contacts with a birthday defined.

try the empty string 🙊 - nevertheless: contacts should register the birthday calendar as described above

georgehrke · 2014-12-15T14:03:47Z

try the empty string 🙊 - nevertheless: contacts should register the birthday calendar as described above

Didn't work either iirc (I actually didn't try %)

DeepDiver1975 · 2014-12-15T14:18:22Z

Didn't work either iirc (I actually didn't try %)

% is added within the implementation - see https://github.com/owncloud/contacts/blob/master/lib/addressbookprovider.php#L124

maybe worth filing an issue against the contacts repo - not really an issue of the api itself

DeepDiver1975 · 2014-12-23T22:18:20Z

please review - thx

@karlitschek @MorrisJobke @georgehrke @Raydiation @PVince81 @schiesbn @butonic

BernhardPosselt · 2014-12-23T23:23:44Z

lib/private/calendarmanager.php

+		public function delete($id, $calendarKey) {
+			$cal = $this->getCalendar($calendarKey);
+			if (!$cal) {
+				return null;


@return says bool if successful

BernhardPosselt · 2014-12-23T23:28:45Z

Can we have some examples how it should be used :)? You can spot usability issues pretty quickly if you see a few lines of code.

BernhardPosselt · 2014-12-24T12:28:52Z

lib/public/calendar/imanager.php

+		 * This function is used to create a new task/event if 'id' is not given or not present.
+		 * Otherwise the task/event will be updated by replacing the entire data set.
+		 *
+		 * @param array $properties this array if key-value-pairs defines a task/event


Can we have a listing of available keys in the phpdoc?

georgehrke · 2014-12-24T12:42:02Z

lib/public/icalendar.php

+
+namespace OCP {
+
+	interface ICalendar {


Could we add a findAll method to get all objects? Or are you just supposed to use search with an empty pattern?

I'd go for an empty pattern on search - I don't want to clutter the interface with a dozen of methods.

DeepDiver1975 · 2015-01-07T12:58:53Z

moving to OC8.1 as we are beyond feature freeze

MorrisJobke · 2015-08-28T18:08:37Z

@DeepDiver1975 I guess this is still valid. Do we want to address this during conf?

DeepDiver1975 · 2015-11-12T09:51:40Z

moving since I don't know where this will go

DeepDiver1975 · 2016-02-03T16:31:57Z

Any app can use caldav to interact with the new caldav backend starting oc9

georgehrke reviewed Oct 7, 2014
View reviewed changes

scolebrook force-pushed the master branch from 4a4ea1d to 9dea79e Compare October 10, 2014 13:32

georgehrke reviewed Oct 11, 2014
View reviewed changes

MorrisJobke added the 2 - Developing label Dec 9, 2014

Introduce public calendar api

f5e3dd4

DeepDiver1975 force-pushed the public-calendar-api branch from 75fc4e9 to f5e3dd4 Compare December 15, 2014 09:41

DeepDiver1975 reviewed Dec 15, 2014
View reviewed changes

MorrisJobke added 3 - To Review and removed 2 - Developing labels Dec 15, 2014

DeepDiver1975 added this to the 8.0-current milestone Dec 23, 2014

BernhardPosselt reviewed Dec 23, 2014
View reviewed changes

BernhardPosselt reviewed Dec 24, 2014
View reviewed changes

georgehrke reviewed Dec 24, 2014
View reviewed changes

DeepDiver1975 modified the milestones: 8.1-next, 8.0-current Jan 7, 2015

nickvergessen added 1 - To develop and removed 3 - To Review labels Feb 19, 2015

LukasReschke changed the title ~~Introduce public calendar api [WIP]~~ [WIP] Introduce public calendar api Feb 24, 2015

DeepDiver1975 modified the milestones: 8.1-current, 8.2-next Apr 2, 2015

georgehrke mentioned this pull request Sep 4, 2015

finish public api design and implement it owncloud/calendar#18

Closed

DeepDiver1975 modified the milestones: 9.0-next, 8.2-current Sep 18, 2015

DeepDiver1975 modified the milestones: backlog, 9.0-current Nov 12, 2015

DeepDiver1975 closed this Feb 3, 2016

DeepDiver1975 deleted the public-calendar-api branch February 3, 2016 16:31

lock bot locked as resolved and limited conversation to collaborators Aug 7, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] Introduce public calendar api #11461

[WIP] Introduce public calendar api #11461

DeepDiver1975 commented Oct 7, 2014

georgehrke Oct 7, 2014

georgehrke Oct 7, 2014

DeepDiver1975 Oct 7, 2014

georgehrke Oct 7, 2014

DeepDiver1975 Oct 7, 2014

georgehrke Oct 7, 2014

DeepDiver1975 Oct 7, 2014

georgehrke Oct 11, 2014

DeepDiver1975 Oct 14, 2014

PVince81 commented Oct 31, 2014

DeepDiver1975 commented Nov 3, 2014

scrutinizer-notifier commented Dec 15, 2014

DeepDiver1975 commented Dec 15, 2014

georgehrke commented Dec 15, 2014

DeepDiver1975 Dec 15, 2014

BernhardPosselt Dec 24, 2014

DeepDiver1975 commented Dec 15, 2014

MorrisJobke commented Dec 15, 2014

DeepDiver1975 commented Dec 15, 2014

georgehrke commented Dec 15, 2014

DeepDiver1975 commented Dec 15, 2014

georgehrke commented Dec 15, 2014

DeepDiver1975 commented Dec 15, 2014

DeepDiver1975 commented Dec 23, 2014

BernhardPosselt Dec 23, 2014

BernhardPosselt commented Dec 23, 2014

BernhardPosselt Dec 24, 2014

georgehrke Dec 24, 2014

DeepDiver1975 Dec 24, 2014

DeepDiver1975 commented Jan 7, 2015

MorrisJobke commented Aug 28, 2015

DeepDiver1975 commented Nov 12, 2015

DeepDiver1975 commented Feb 3, 2016

[WIP] Introduce public calendar api #11461

[WIP] Introduce public calendar api #11461

Conversation

DeepDiver1975 commented Oct 7, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PVince81 commented Oct 31, 2014

DeepDiver1975 commented Nov 3, 2014

scrutinizer-notifier commented Dec 15, 2014

DeepDiver1975 commented Dec 15, 2014

georgehrke commented Dec 15, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DeepDiver1975 commented Dec 15, 2014

MorrisJobke commented Dec 15, 2014

DeepDiver1975 commented Dec 15, 2014

georgehrke commented Dec 15, 2014

DeepDiver1975 commented Dec 15, 2014

georgehrke commented Dec 15, 2014

DeepDiver1975 commented Dec 15, 2014

DeepDiver1975 commented Dec 23, 2014

Choose a reason for hiding this comment

BernhardPosselt commented Dec 23, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DeepDiver1975 commented Jan 7, 2015

MorrisJobke commented Aug 28, 2015

DeepDiver1975 commented Nov 12, 2015

DeepDiver1975 commented Feb 3, 2016