Skip to content
This repository has been archived by the owner on Jun 10, 2024. It is now read-only.

Commit

Permalink
First stage of supporting floating timezone for propfind_caldata
Browse files Browse the repository at this point in the history 
This will depend on having somewhere to hang the floatingtz in a
structure that gets created during the request, and there's nothing
there yet
  • Loading branch information
@brong
brong committed Jan 5, 2018
1 parent b4a5a73 commit 9ae1fb9
Showing 1 changed file with 6 additions and 5 deletions.
11 changes: 6 additions & 5 deletions imap/http_caldav.c
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5346,7 +5346,8 @@ static int expand_cb(icalcomponent *comp,
/* Expand recurrences of ical in range.
NOTE: expand_cb() is destructive of ical as it builds expanded_ical */
static icalcomponent *expand_caldata(icalcomponent **ical,
struct icalperiodtype range)
struct icalperiodtype range,
icaltimezone *floatingtz)
{
icalcomponent *expanded_ical =
icalcomponent_vanew(ICAL_VCALENDAR_COMPONENT,
Expand All @@ -5360,10 +5361,10 @@ static icalcomponent *expand_caldata(icalcomponent **ical,
if (prop)
icalcomponent_add_property(expanded_ical, icalproperty_new_clone(prop));

icalcomponent_myforeach(*ical, range, NULL, expand_cb, expanded_ical);
icalcomponent_myforeach(*ical, range, floatingtz, expand_cb, expanded_ical);
icalcomponent_free(*ical);
*ical = expanded_ical;

return *ical;
}

Expand Down Expand Up @@ -5525,7 +5526,7 @@ static int propfind_caldata(const xmlChar *name, xmlNsPtr ns,
ical = fctx->obj;

if (partial->expand) {
fctx->obj = expand_caldata(&ical, partial->range);
fctx->obj = expand_caldata(&ical, partial->range, NULL);
}
else limit_caldata(ical, &partial->range);
}
Expand Down Expand Up @@ -7114,7 +7115,7 @@ static void combine_vavailability(struct freebusy_filter *fbfilter)
unsigned i, j;

memset(&availfilter, 0, sizeof(struct freebusy_filter));
availfilter.floatingtz = fbfilter.floatingtz;
availfilter.floatingtz = fbfilter->floatingtz;

/* Sort VAVAILABILITY periods by priority and start time */
qsort(vavail->vav, vavail->len,
Expand Down

6 comments on commit 9ae1fb9

@ksmurchison
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, after looking at the code and thinking about this for 1/2 a day or so, my suggestion for propfind_caldata(), to support both calendar-query and calendar-multiget, is to create a hash table keyed by mailbox name with the data value being the floating tz component and store it in struct partial_caldata_t. If it wasn't for multiget we could have a caldav_propfind_by_collection() which did nothing by fetch the floating tz and then passes off to propfind_by_collection(). But since mutliget is random, we can't assume that we get the URLs sorted by mailbox.

@brong
Copy link
Owner Author

@brong brong commented on 9ae1fb9 Jan 7, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They're basically always going to be sorted by mailbox, so we can just close and open if the mboxname is changed. If somebody sends a pathological request, they get a pathological response.

@ksmurchison
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we actually know that multiget URLs are sorted by collection? If so, then my caldav_propfind_by_collection() idea is simpler

@brong
Copy link
Owner Author

@brong brong commented on 9ae1fb9 Jan 7, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly you're only multigetting from a single collection at once, based on clients I've seen.

@brong
Copy link
Owner Author

@brong brong commented on 9ae1fb9 Jan 7, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And even if not, they probably iterate over the collection list and add them to the XML of the request - unless they're using a hash locally and not sorting, which would be a pretty lame client.

@ksmurchison
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're probably right. Although the Apple client does prefer to do a sync-collection on calendar-home-set (which we don't currently support) and could theoretically have scrambled URLs, but I doubt it. I'm cool with your assumption until a lousy client proves otherwise.

Please sign in to comment.