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

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

On Wed, Dec 2, 2015, at 11:18 AM, Linhui Sun wrote:
> Hi
>
> On 周三, 12月 2, 2015 at 17:56,  Hugo González Labrador
> <[e-mail]> wrote:
>>
>>
>>
>> On Wed, Dec 2, 2015, at 08:20 AM, Linhui Sun wrote:
>>> Hi
>>>
>>> 2015-12-02 5:14 GMT+08:00 Hugo González Labrador
>>> <[e-mail]>:
>>>> Hi,
>>>>
>>>> from my point of view the remoteStorage project addresses a subset
>>>> of the use cases of the  WebDAV specification.
>>>>
>>>> The main difference I can observe is that the specification is
>>>> built on REST instead of XML-based communication.
>>>>
>>>> I personally like much more REST than WebDAV because it is more
>>>> developer friendly and it is faster to develop. Maybe the
>>>> remoteStorage API becomes the next WebDAV :)
>>>>
>>>> However, the remoteStorage API does not provide a way of
>>>> synchronising data, this task is delegated to the developers. Is
>>>> there a plan to provide such feature based on the outcome of this
>>>> draft?
>>> I'm a little bit confused why you say the remoteStorage does not
>>> provide that. Is that because remoteStorage does not perform like
>>> a typical sync services (e.g. dropbox...) or you are saying
>>> something else?
>> Yes, because it does not offer synchronisation capabilities.
> Got it. And What I am wondering is that do we need to include those
> capabilities in a base specifications. Since it is hard to standardize
> the capabilities like dedup or delta. Maybe a better way is to define
> those in a separate specification, something like extensions. For a
> base document, we just need to define how to perform sync operations.

Yes, I agree that may be  an extension of this draft could handle the
synchronisation part.

>>
>>>>
>>>> BTW, I want to introduce ClawIO (http://clawio.github.io), a
>>>> research project to benchmark different synchronisation protocols
>>>> against different data backends with special attention to provide a
>>>> common sync API.
>>>>
>>>> A common API for different sync protocols is being created based on
>>>> the architecture specified in this draft (control and data servers)
>>>> and the
>>> I cannot find a distributed architecture in this draft. It seems
>>> that they handle metadata and content data together, just like a
>>> normal web service.
>>
>> ClawIO is fully distributed. Every logical unit is a different server
>> than be scaled out. Data and Metadata channels are independent from
>> each other and reside on different servers.
> That is widely employed in popular sync services. And that is also
> beneficial to privacy to some extent. But in the context of sync in
> browser (which is mainly considered in the remoteStorage), I don't
> know whether this is reasonable. But I think we should deploy
> distributed architecture although it will make things complicated.

Of course, the remoteStorage is targeted to browsers, so syncing does
not make too much sense in this case. With the rise of Linux container
micro-service based architectures, the deployment of  such highly
complex systems should become easier and faster.

Best,

Hugo

> Regards, Linhui
>>
>>
>>> Regards, Linhui
>>>> one from the CERN EOS project (management, disk and queue servers).
>>>>
>>>> The Phase I has implemented the ownCloud Sync Protocol and Phase II
>>>> will implement the SeaFile Sync Protocol. The choice of these
>>>> protocols among others is because they are really opposed to each
>>>> other in terms of syncing (delta vs non-delta, state-based vs log/event/git-
>>>> based sync …), so finding a common approach is more challenging.
>>>>
>>>> Providing a base specification/architecture to measure the
>>>> feasibility of this draft is one of the objectives of the project.
>>>>
>>>> I believe that the work being done here and in ClawIO are
>>>> supplementary to each other and I think mutual collaboration could
>>>> be beneficial for both sides.
>>>>
>>>> Also, if there is interest, the remoteStorage API can be added to
>>>> ClawIO.
>>>>
>>>> Best regards,
>>>>
>>>> Hugo Gonzalez Labrador
>>>>
>>>> On Tue, Dec 1, 2015, at 09:00 PM, [e-mail]
>>>> wrote:
>>>> > Send Storagesync mailing list submissions to
>>>> > [e-mail]
>>>> >
>>>> > To subscribe or unsubscribe via the World Wide Web, visit
>>>> > https://www.ietf.org/mailman/listinfo/storagesync or, via email,
>>>> > send a message with subject or body 'help' to       storagesync-
>>>> > [e-mail]
>>>> >
>>>> > You can reach the person managing the list at       storagesync-
>>>> > [e-mail]
>>>> >
>>>> > When replying, please edit your Subject line so it is more
>>>> > specific than "Re: Contents of Storagesync digest..." Today's
>>>> > Topics:
>>>> >
>>>> >1. New version of draft-dejong-remotestorage    Internet-Draft
>>>> >available (Michiel de Jong)    2. Re: New version of draft-dejong-
>>>> >remotestorage Internet-Draft       available (Gihan Dias)    3.
>>>> >Re: New version of draft-dejong-remotestorage Internet-Draft
>>>> >available (Fei Song)
>>>> > _______________________________________________
>>>> > Storagesync mailing list [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/storagesync Email had 3
>>>> > attachments:
>>>> > + [Storagesync] New version of draft-dejong-remotestorage Internet-
>>>> >   Draft available   2k (message/rfc822)
>>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage Internet-
>>>> >   Draft available   1k (message/rfc822)
>>>> > + Re: [Storagesync] New version of draft-dejong-remotestorage Internet-
>>>> >   Draft available   2k (message/rfc822)
>>>>
>>>> _______________________________________________
>>>> Storagesync mailing list [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/storagesync
>>