WebDAV sync last call

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

WebDAV sync last call

Cyrus Daboo-2
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.

--
Cyrus Daboo


Reply | Threaded
Open this post in threaded view
|

Re: WebDAV sync last call

Andrew McMillan-5
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.
------------------------------------------------------------------------


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WebDAV sync last call

Julian Reschke
On 2011-12-14 08:29, Andrew McMillan wrote:

> ...
> (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.
> ...

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

Reply | Threaded
Open this post in threaded view
|

Re: WebDAV sync last call

Andrew McMillan-5
On Wed, 2011-12-14 at 09:54 +0100, Julian Reschke wrote:

> On 2011-12-14 08:29, Andrew McMillan wrote:
> > ...
> > (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.
> > ...
>
> 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).
Yes, those are good points.

Regards,
                                        Andrew.

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


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WebDAV sync last call

Cyrus Daboo-2
In reply to this post by Andrew McMillan-5
Hi Andrew,

--On December 14, 2011 8:29:13 PM +1300 Andrew McMillan
<[hidden email]> wrote:

> (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.

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


Reply | Threaded
Open this post in threaded view
|

Re: WebDAV sync last call

Cyrus Daboo-2
In reply to this post by Andrew McMillan-5
Hi Andrew,

--On December 14, 2011 8:29:13 PM +1300 Andrew McMillan
<[hidden email]> wrote:

> (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.

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