Hi Ján,
I just looked at RFC 4791 and it certainly looks like this SHOULD be supported by all servers:
If the Request-URI is a collection resource, then the DAV:href elements MUST refer to calendar object resources within that collection, and they MAY refer to calendar object resources at any depth within the collection. As a result, the "Depth" header MUST be ignored by the server and SHOULD NOT be sent by the client.
Note that it states that the resource may be "at any depth within the collection".
I just tested this on my server and I can fetch objects from 2 different calendars by using the calendar-home-set as the target resource of the request as in your example.
On 09/11/2013 05:17 PM, Ken Murchison wrote:
I wouldn't be surprised if some of the existing servers already support such requests. I will have to do some testing on my server to see if I support it (I'm thinking that I do). I suppose I also need to look at the CalDAV spec to see if its allowed. The other alternative is to pipeline the requests, so rather than 2 or more roundtrips you just have 1.
On 09/11/2013 04:12 PM, Ján Máté wrote:
Hi Ken,
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 biggest problem in JavaScript is the number of requests :-/
For example cross-collection calendar-multiget REPORT can extremely speed-up our clients and it requires minimal changes in servers.
Instead of:
REPORT /user/collection/
<calendar-multiget> <href>a.ics</href> <href>b.ics</href> </calendar-multiget>
REPORT /user/another-collection/
<calendar-multiget> <href>x.ics</href> <href>y.ics</href> </calendar-multiget>
why to not support:
REPORT /user/
<calendar-multiget> <href>collection/x.ics</href> <href>collection/y.ics</href> <href>another-collection/x.ics</href> <href>another-collection/y.ics</href> </calendar-multiget>
It can speed up lot of clients ...
JM
On Sep 11, 2013, at 9:52 PM, Ken Murchison <murch@andrew.cmu.edu mailto:murch@andrew.cmu.edu> wrote:
Hi Ján,
If you're working towards less traffic over the wire, you could use the "return=minimal" Preference with your PROPFIND, REPORT, and PROPPATCH requests:
https://datatracker.ietf.org/doc/draft-murchison-webdav-prefer/
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 :-)
JM
On Sep 11, 2013, at 4:45 PM, Graf von Roit zu Hoya <graf.roit@gmail.com mailto:graf.roit@gmail.com> wrote:
Hello,
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!
Rudolf
Am 10.09.13 15:22, schrieb Ján Máté:
Yes,
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.
JM
On Sep 10, 2013, at 12:02 PM,rog7993@web.de wrote:
> Addition: > > 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. > > Ingo >
--
Rudolf Graf von Roit zu Hoya *E-Mail:* graf.roit@gmail.com
-- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
-- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
Hi Ken,
this sounds very good. Last time (1-2 months back) we tried this type of request with DAViCal we got an error ...
I will ask Andrew for fix :-)
JM
On Sep 11, 2013, at 11:34 PM, Ken Murchison murch@andrew.cmu.edu wrote:
Hi Ján,
I just looked at RFC 4791 and it certainly looks like this SHOULD be supported by all servers:
If the Request-URI is a collection resource, then the DAV:href elements MUST refer to calendar object resources within that collection, and they MAY refer to calendar object resources at any depth within the collection. As a result, the "Depth" header MUST be ignored by the server and SHOULD NOT be sent by the client.Note that it states that the resource may be "at any depth within the collection".
I just tested this on my server and I can fetch objects from 2 different calendars by using the calendar-home-set as the target resource of the request as in your example.
On 09/11/2013 05:17 PM, Ken Murchison wrote:
I wouldn't be surprised if some of the existing servers already support such requests. I will have to do some testing on my server to see if I support it (I'm thinking that I do). I suppose I also need to look at the CalDAV spec to see if its allowed. The other alternative is to pipeline the requests, so rather than 2 or more roundtrips you just have 1.
On 09/11/2013 04:12 PM, Ján Máté wrote:
Hi Ken,
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 biggest problem in JavaScript is the number of requests :-/
For example cross-collection calendar-multiget REPORT can extremely speed-up our clients and it requires minimal changes in servers.
Instead of:
REPORT /user/collection/
<calendar-multiget> <href>a.ics</href> <href>b.ics</href> </calendar-multiget>
REPORT /user/another-collection/
<calendar-multiget>
<href>x.ics</href> <href>y.ics</href></calendar-multiget>
why to not support:
REPORT /user/
<calendar-multiget>
<href>collection/x.ics</href> <href>collection/y.ics</href> <href>another-collection/x.ics</href> <href>another-collection/y.ics</href></calendar-multiget>
It can speed up lot of clients ...
JM
On Sep 11, 2013, at 9:52 PM, Ken Murchison murch@andrew.cmu.edu wrote:
Hi Ján,
If you're working towards less traffic over the wire, you could use the "return=minimal" Preference with your PROPFIND, REPORT, and PROPPATCH requests:
https://datatracker.ietf.org/doc/draft-murchison-webdav-prefer/
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 :-)
JM
On Sep 11, 2013, at 4:45 PM, Graf von Roit zu Hoya graf.roit@gmail.com wrote:
Hello,
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!
Rudolf
Am 10.09.13 15:22, schrieb Ján Máté: > Yes, > > 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. > > > JM > > On Sep 10, 2013, at 12:02 PM, rog7993@web.de wrote: > >> Addition: >> >> 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. >> >> Ingo >>
-- Rudolf Graf von Roit zu Hoya E-Mail: graf.roit@gmail.com
-- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
-- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
-- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
-
Ján Máté -
Ken Murchison