thanks - I added this functionality to my todo list.
Is there any similar RFC to minimize the number of HTTP requests to the server? The
For example cross-collection calendar-multiget REPORT can extremely speed-up our clients
and it requires minimal changes in servers.
why to not support:
It can speed up lot of clients ...
On Sep 11, 2013, at 9:52 PM, Ken Murchison <murch(a)andrew.cmu.edu> wrote:
If you're working towards less traffic over the wire, you could use the
"return=minimal" Preference with your PROPFIND, REPORT, and PROPPATCH requests:
Its supported by my server, DAViCal, Bedework, and Apple as noted in the draft.
On 09/11/2013 12:40 PM, Ján Máté wrote:
> Hi Rudolf,
> it is not as easy as looks like. Currently a collection can be visible or hidden (but
always loaded). The feature you want will cause lot of problems, e.g.:
> - how to add 3rd state (not loaded) to the interface and teach users what is the
difference between the not loaded and not visible collection
> - this functionality will break the globalShowHiddenAlarms=true option (hidden
collection != do not show alarms from this collection)
> - if you load a collection each time when user clicks to a checkbox, you can/will
crash your browser (~ 30 concurrent requests /30 enabled collections/ = browser crash) ...
=> it requires request queue
> - if we load all collection at once, we can reduce the number of requests to the
server - we can get sync-token changes from one PROPFIND request instead of N
> CalDavZAP 0.10.0 will add time-range synchronization, so you can configure number of
months you want to load from past (default 1) and future (default 1). If you don't
change these configuration options then your client will load only 3 months of data (if
you set both options to 0, then only 1 month). The rest of data will be loaded only if you
click to date out of the already downloaded time-range (it will extend the
"window" of downloaded data). If you use DAViCal or other "good"
server with support for time-range filtering and sync-collection REPORT then CalDavZAP
will be REALLY FAST.
> RC1 coming tonight or tomorrow :-)
> On Sep 11, 2013, at 4:45 PM, Graf von Roit zu Hoya <graf.roit(a)gmail.com>
>> i watched this thread as it is very interesting to me, too. After applying the
patch, now the selection of calendars is persistent. But one thing is a little bit
confusing: deselected calendars are hidden in the interface but still get loaded when the
gui starts up. Wouldn't it be a better performance, if the hidden calendars are only
loaded on demand? Only when the user activates the deselected items again? With the
settings remembered, i now don't see my archive calendars in the gui. But startup
still take a long time.
>> Just to say: it is a great enhancement, that the settings are now remembered!
MANY thanks for this option and the software itself!
>> Am 10.09.13 15:22, schrieb Ján Máté:
>>> this is true ... we store the URL with the domain name because if you use
multiple CardDAV accounts we need to distinguish between identical collection names.
>>> On Sep 10, 2013, at 12:02 PM, rog7993(a)web.de wrote:
>>>> I got an idea what went wrong yesterday. It seems, that the saved
>>>> settings are dependent of the server name, one use for connecting to
>>>> CalDavZAP. The server, on which CalDavZAP and Davical runs, can be
>>>> reached with two different DNS names or better domains. Maybe I used one
>>>> in Firefox and the other on Chrome.
>> Rudolf Graf von Roit zu Hoya
>> E-Mail: graf.roit(a)gmail.com
Principal Systems Software Engineer
Carnegie Mellon University