New Framework Review: KDAV

[Volker Krause]

On Saturday, 4 April 2020 17:41:09 CEST Ingo Klöcker wrote:
> On Samstag, 4. April 2020 16:20:21 CEST Kevin Ottens wrote:
> > I'm likely late to the party, but here is what I found by looking at KDAV
> > 
> > master today (first day of the KDE PIM sprint):
> >  * We might want to do something about "ctag" in DavCollection it's a bit
> > 
> > obscure as a name (and the API doc doesn't help), also it seems to not be
> > an official standard (while being widely supported) and there's the
> > sync-token mechanism which has a RFC (RFC6578);
> 
> CTag appears to be an Apple-specific CalDAV extension (see
> https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/calda
> v-ctag.txt) This document explicitly states
> =====
>    IMPORTANT: The feature defined by this specification is now
>    deprecated in favor of support for the WebDAV Sync REPORT as defined
>    by [RFC6578].  Clients MUST NOT rely on this feature to detect
>    changes to collections, instead they MUST support the WebDAV Sync
>    REPORT.  Servers MUST support the WebDAV Sync REPORT to allow clients
>    to efficiently synchronize calendar collections.  Whilst most modern
>    clients do support the WebDAV Sync REPORT, servers MAY continue to
>    support this specification by simply using the DAV:sync-token
>    property value for the getctag property value, in order to provide
>    backwards compatibility with old clients.
> =====
> i.e. CTag is deprecated since almost 5 years in favor of DAV:sync-token.
> 
> We should probably still keep it as-is (and later add setSyncToken()/
> syncToken() when we need it).
> 
> >  * Same comment about etag for DavItem than the ctag one for DavCollection
> 
> ETag is a well-known concept in HTTP 1.1 and it's usage for WebDAV is
> specified in https://tools.ietf.org/html/rfc4918#section-8.6. I would keep
> the name because any other name would confuse people knowing (Web)DAV.

Thanks, added those references to the API docs.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20200406/6b0684dc/attachment-0001.sig>