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

["Fei Song" <[e-mail]>]

Hi

Sorry for the late reply, Please see it inline~


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

Indeed！This is why I said the synchronization should be mentioned at the abstract.
Otherwise, it seems that the remoteStorage draft only focus on browser-based storage.


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