Subject: Re: WebDAV sync last call

From: Andrew McMillan <[email-masked]>
Date: Wed, 14 Dec 2011 20:29:13 +1300

On Tue, 2011-08-30 at 09:38 -0400, Cyrus Daboo wrote:
> Hi folks,
> The authors believe the WebDAv Sync document 
> (<https://datatracker.ietf.org/doc/draft-daboo-webdav-sync/>) is ready to 
> go to the IESG for consideration of publishing as an RFC. We'd like to get 
> final reviews from this list along with a list of existing or planned 
> implementations of this draft to include as supporting documentation for 
> the IESG. Please review and provide feedback, thanks.

Hi Cyrus,

There are a couple of things that have come up for me recently in
relation to this draft.  I'll spell them out here, but I'm happy enough
with the draft as it stands, and I would rather see this approved than
for my issues (or maybe "wild ideas" might be a better term :-) to
disrupt the process.

(1) invalid sync token error

When I send a token which is invalid I receive an error response.  This
is not particularly useful to me in my client.  I (somehow) got an
invalid sync token - maybe it expired - but there's probably no useful
interaction with the user that I can take as a result.  I just have to
fall back to a full re-sync.  It seems to me that it would be more
useful to treat this case the same as if no sync token were supplied,
perhaps also supplying additional information that the sync token was
(expired|invalid|...) within the response.

DAViCal was in fact doing this (without error information) until I
recently corrected the error.

(2) long polling

When I make a sync request I would sometimes like to be able to indicate
to the server that it is acceptable for it to treat my request as a
"long poll", so that the server would hold my connection open until a
change occurred within the hierarchy of the request.

For a server to do this, I think that it would be advantageous for the
old sync token to be provided within the request headers, rather than
within the XML payload of the request.  I believe that doing this would
make server processing easier, since all necessary data for deciding
whether changes have occurred (URL, Depth, Token) would be in the
headers.

There's nothing I can see in the current spec which would actually
preclude implementation of the report as a long poll, but if one were to
actually do that it might be less than ideal for some clients.  On the
other hand if the possibility is available in a "soft" way as an
optional implementation then a client hoping for support could easily be
written to work just fine with an non-supporting installation.

For example if the client indicated a long poll response was acceptable
simply by including a "Sync-Token" header containing the old token, an
unknowing implementation would simply respond, as at present.  A knowing
implementation could hold responding until something changed.  The
client written to support this would want to know that this was a long
poll, so it could immediately re-request, so the server could also
indicate this by providing the sync token back as a header.

Cheers,
					Andrew.

-- 
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
        There is no snooze button on a cat who wants breakfast.
------------------------------------------------------------------------

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2011 09:54:47 +0100

On 2011-12-14 08:29, Andrew McMillan wrote:
> ...
> ...

How does this help? The request body fur the REPORT is sufficiently 
small to be inspected right away, no?

The important part for the ability to stream the change events is that 
the new sync token is last in the response body, and the sync spec got 
that right...

(Mentioning this because I'm using Atom for a similar use case in JCR, 
and that suffers from the ETag having to be sent out first, with 
libraries and server frameworks having no support for trailers).

Best regards, Julian

---

From: Andrew McMillan <[email-masked]>
Date: Wed, 14 Dec 2011 22:29:42 +1300

> libraries and server frameworks having no support for trailers).

Yes, those are good points.

Regards,
					Andrew.

-- 
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
           This fortune is inoperative.  Please try another.
------------------------------------------------------------------------

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 14 Dec 2011 10:03:51 -0500

Hi Andrew,

> recently corrected the error.

I would prefer to keep invalid vs no sync-token behavior separate. My 
rationale is that when an invalid token is presented, and the server is 
going to force the client to go back to a full sync, it is imperative that 
the client know that since it will either have to purge its current cache 
prior to a full sync, or treat the full sync results in a significantly 
different way than it would if it were an incremental sync.

Now one way to achieve that would be as you describe, with the addition of 
some indication from the server that it fell back to a full sync so the 
client can change from incremental to full behavior. We don't have such an 
indication now, and I would be reluctant to add one.

The other issue here is that a client may want to do full syncs differently 
from incremental. e.g., if the collection is known to be very large, the 
client may not want to get all the resource data in a single full sync 
response, instead opting to use the DAV:limit option to "batch" the full 
sync results. With your approach, the server would return the full set of 
data (unless the client had uses limit for incremental). Also, I know that 
CalDAV clients doing time-range based sync'ing have special logic that 
means they often don't use sync report for a full sync.

At this point I prefer the two-step process as it gives clients the 
flexibility to choose how and when a full sync is initiated. I don't think 
it is all that big a burden on clients and the extra roundtrip is 
reasonable given that this is an edge case that should not occur very 
frequently.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 14 Dec 2011 10:17:25 -0500

Hi Andrew,

> change occurred within the hierarchy of the request.

I think a long polling option should be implemented as an extension to 
WebDAV sync. The issue with long polling right now is that there is no 
agreed upon standard way of doing that. I'd rather wait for a standards 
based approach to be defined - but WebDAV sync itself should not be blocked 
on that.

-- 
Cyrus Daboo