[caldeveloper-l] sync-tokens vs PROPFIND

[Helge Heß]

Hi,

>>>>> We have a situation where a Calendar client is trying to get the etags of every event in an enormous calendar in a single query. Naturally, this isn't working. 

I think this is a straight forward thing, why wouldn’t that be working? First of all, you would stream the etags and content types, there is nothing in the protocol which prohibits that. It just works w/ arbitrarily large calendars.

And even *if* you would want to assemble the whole response in memory first - I mean how big is that calendar? Even w/ 100k events, the response would be what, 10KB of plain text?. Even a million events would be maybe 100KB at most. That is nothing even for a Raspi.

As an optimisation, you could already compress the response in memory, which makes stuff even smaller. Maybe around 2-3KB for 100k events and 10KB or less for 1m events.


> Another look at the RFC suggests that a perfectly reasonable thing to do when faced with a very large query is to return what we can with a 507 number-of-matches-within-limits error. Apart from being more conformant, this should allow them to sync something, rather than nothing at all, which is an improvement. (Although it's quite possible that the buggy client will see the 507, assume it's a fatal error, and ignore the payload.)

I haven’t seen a client doing paging yet. Are there any clients supporting/using this?

>>>>> I have an RFC question I'd appreciate some feedback on... 
>>>>> 
>>>>> We have a situation where a Calendar client is trying to get the etags of every event in an enormous calendar in a single query. Naturally, this isn't working. 
>>>>> 
>>>>> They're doing this: 
>>>>> 
>>>>> PROPFIND /caldav/v2/$USERNAME/events 
>>>>> <?xml version="1.0" encoding="UTF-8"?> 
>>>>> <A:propfind xmlns:A="DAV:"> 
>>>>>   <A:prop> 
>>>>>     <A:getcontenttype/> 
>>>>>     <A:getetag/> 
>>>>>   </A:prop> 
>>>>> </A:propfind> 

If they do this, they very likely are not supporting sync-reports at all. Which is fine, they are allowed to do this.


>>>>> Is it permissable to return a sync-token (and expect the client to honour it) /even if the client's original query didn't ask for it/? 

What use would that have? The client clearly doesn’t support sync-report. (nor does sync report solve your issue, because the initial report would still need to return the whole thing).


I mean, if you really can’t do it w/ your backend, I don’t know what your options are. Even if the client would support sync-report (which it doesn’t have to), it wouldn’t really solve your problem. Because it would quite likely still not support batching (which it doesn’t have to either).

It is a little hard to give advise if we don’t know how your backend works. I personally haven’t see a backend where streaming is impossible (it just usually is extra work), nor where collecting 10KB of data in memory is a insurmountable issue.

hh