Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1

[Markus Unterwaditzer <[e-mail]>]

On Thu, Dec 03, 2015 at 10:44:42AM +0100, François Kooman wrote:
> On 12/03/2015 10:06 AM, [e-mail] wrote:
> > If we really want to discuss the Pros and Cons of WebDAV, can we
> > mark these three reasons as disadvantages of WebDAV? any support for
> > that?
> 
> Personally, I do not think that is fair.
> 
> > 1) it's a lot of work to implement this without using an existing
> > WebDAV library 
> 
> I do not see a problem in reusing an existing WebDAV library. This has
> the added benefit that you get a lot of functionality 'for free' and
> that existing test suites are available for testing compatibility. This
> is purely a practical argument!
> 
> > 2) in practice, a lot of WebDAV servers get it wrong,
> > or don't implement all of WebDAV. It's very annoying for client
> > implementers to have to deal with servers that e.g. chose not to
> > implement LOCK and UNLOCK. 
> 
> The point is not to have a fully compliant (whatever that is exactly)
> WebDAV server. Either this ML (or remoteStorage specification) could
> determine a subset of WebDAV that would be required to be implemented.
> E.g. we exhaustively list the verbs that need to be implemented and
> their expected behavior. If we keep this a limited as possible and stay
> away from experimental features we have a high probability that most
> libraries will get it right! If we stay away from locking and ACLs the
> library situation looks a lot brighter :)

WebDAV's syntax is excessively verbose to allow non-standard properties on
files and folders, non-standard querying methods for `calendar-multiget`,
PROPFIND and friends, and etc. The whole point of XML is extensibility at the
cost of verbosity.

If you take that away from your newly defined subset of WebDAV, what is left? A
new protocol which 

- requires extra requests for creating and deleting folders (while there's
  nothing left that would speak against implicitly creating those). Sure you
  have GET, PUT, DELETE for documents

- has excessively verbose syntax for listing folders, but without the advanced
  filtering capabilities.

- is not backwards-compatible with most client implementations and therefore
  has to be rebranded as a new protocol so users don't try to plug a "full"
  WebDAV client into a server that only implements your subset

Especially that last one. If you're going to slice off 90% of WebDAV's
features, you might as well define a new, clean protocol.

> 
> > 3) we don't really need all these advanced
> > features on top of standard HTTP, just supporting GET/PUT/DELETE for
> > resources, and adding a simple folder description format, is enough
> > for most applications.
> 
> Exactly!
> 
> > For the target of our ISS group, whether the WebDAV can be reused is 
> > critical.
> 
> Well, my point is that there is little reason to reinvent the wheel if
> the only benefit is to use JSON instead of XML for folder listings. The
> amount of experience and available tooling for WebDAV is already huge!
> It would be a waste to throw this away just for liking JSON better.
> 
> But maybe there are other reasons using (a limited set of) WebDAV is
> impossible or unwanted...
> 
> Cheers,
> François
> 
> _______________________________________________
> Storagesync mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storagesync