Re: WebDAV sync last call

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