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

[Hugo González Labrador <[e-mail]>]

If clients need to be polyglot, then I don't see the need for remoteStorage or this draft, in the end, they will be other standards that clients need to implement (3rd image of https://xkcd.com/927/) 

There are already a bunch of polyglot sync clients,
https://crosscloud.me/ as an example. The problem with such client is
that they have to deal with N different protocols.

I thought the objective of this draft was to avoid such situation and
let the cloud provider implement a common standard (the one we are
seeking for).


On Thu, Dec 3, 2015, at 10:52 AM, Michiel de Jong wrote:
> I think we should not (try to) pick one protocol -
> https://xkcd.com/927/ I think sync *clients* should be "protocol
> polyglots" in the same way as
> https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#Protocol_support
>
> On Thu, Dec 3, 2015 at 10:44 AM, François Kooman
> <[e-mail]> 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 :)
>>
>>
> 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