Subject: [Storagesync] recent issues discussed

From: "Fei Song" <[email-masked]>
Date: Wed, 2 Dec 2015 10:58:56 +0800

I add this into "recent issues discussed". Here is the latest version:
 
1. The design targets of WebDAV, rsync and other existing approaches?
2. The potential use cases of ISS, such as client/server, git-like pattern, svn, etc.
3. The efficiency improvements might be the second goal for standardizing ISS protocol
4. CORS headers on storage sync APIs
5. What is needed for the ISS: a sync protocol or a generalized API
6. Some related organizations, events, projects, etc.: GEANT community, OpenCloudMesh, ownCloud, CS3, remoteStorage, ClawIO

--------------
Fei Song
>2015-11-26 11:28 GMT+08:00 Fei Song <[email-masked]>:
>
>> BTW, Based on the last sentence of last email:"The intention of this
>> message is to investigate the current state of using WebDAV for sync
>> purposes to see what needs to be improved here and whether we need new
>> protocols"
>>
>> The outcome he/she wanted might be just the links like
>> http://cs3.ethz.ch/program.html :)
>>
>In another word, I think what I want finally might be a discussion about
>"What is needed for the ISS: a sync protocol or a generalized API". Sorry
>for the poor expression : )
>
>Regards,
>Linhui
>
>>
>>
>> --------------
>> Fei Song
>> >Hello,
>> >
>> >What kind of outcome are you looking for with this analysis? Some
>> research in this area has already been done or is being done as we speak
>> >
>> >e.g. "A study of delta-sync and other optimisation in HTTP/Webdav
>> synchonisation protocols"
>> >
>> >see "Technology and Research":
>> >
>> >http://cs3.ethz.ch/program.html
>> >
>> >It would be interesting to see if there is a potential for collaboration.
>> Or maybe we already have some information you are looking for.
>> >
>> >Best regards,
>> >
>> >Jakub Moscicki
>> >
>> >―
>> >
>> >
>> >On 25 Nov 2015, at 11:45, Linhui Sun <[email-masked]<mailto:
>> [email-masked]>> wrote:
>> >
>> >Hi all,
>> >
>> >As I mentioned before, I think the developers could benefit from the IETF
>> standards. The ownCloud (https://owncloud.org/) is just an example. It is
>> developed for those who do not trust commercial storage services and want
>> to build their own network-based storage services. The ownCloud is using
>> WebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV is designed for
>> distributed work but not for the sync. Thus, I made some preliminary
>> investigations on how the ownCloud uses WebDAV for sync purposes. A brief
>> summary of what I've found is in the following, please correct me if I am
>> wrong.
>> >
>> >I installed the ownCloud server (v8.2.1) on the CentOS7, and the client
>> is a desktop client on Windows.
>> >
>> >1. To find whether there is a change to the synced directory, the client
>> continuously sends PROPFIND to the server at regular intervals (around 34
>> seconds under my observation). The server will respond a 207 Multi-Status
>> Response to tell whether the main directory has been changed. To perform
>> this regular check, the client will open a new TCP connection to send the
>> PROPFIND, the server will close the existing TCP connection after
>> responding the 207 Multi-Status Response. For the next check, the client
>> will open another new TCP connection.
>> >
>> >2. Every time adding (or creating) a new file to the local folder, the
>> client will open a new TCP connection (if there is no connection existing)
>> to send the file asap. The client will first send several PROPFINDs to find
>> out which sub-directory has been changed. And then it sends the file using
>> PUT. The server will respond a 201 Created Response and then terminate the
>> connection. Currently, I haven't found any application layer chunking, all
>> the segmentation are performed by TCP.
>> >
>> >3. Every time I delete (or rename) a file locally, the client will also
>> open a new TCP connection to send several PROPFINDs to find out which file
>> has been removed (or renamed). Then it will send DELETE (or MOVE). The
>> server will respond a 204 No Content Response (or 201 Created Response) and
>> then terminate the connection.
>> >
>> >4. I open a file and frequently edit and save it (actually this is what I
>> usually do with the Dropbox). The client will send the whole file to the
>> server every time I save the file.
>> >
>> >To summarize, it seems that the ownCloud makes heavily use of PROPFIND to
>> achieve the sync process. Each sync operation (e.g. upload, modify and
>> etc.) will start with sending one or more PROPFINDs. And currently, if I
>> add a file to the server (directly from the server side via web interface),
>> the client cannot find the change. I need to interrupt the sync and recover
>> it to make the client be aware of the change and download the newly added
>> file. I'm not sure whether this is caused by the sync mechanism or an
>> improper server configuration. I need to investigate this further and also
>> how the ownCloud works for multiple clients (or devices).
>> >
>> >For ISS, I think ownCloud has demonstrated to some extent that similar
>> IETF protocols could be deployed and employed. The intention of this
>> message is to investigate the current state of using WebDAV for sync
>> purposes to see what needs to be improved here and whether we need new
>> protocols.
>> >
>> >Comments are welcome : )
>> >
>> >Regards,
>> >Linhui
>> >
>> >
>> >_______________________________________________
>> >Storagesync mailing list
>> >[email-masked]<mailto:[email-masked]>
>> >https://www.ietf.org/mailman/listinfo/storagesync
>> >
>> _______________________________________________
>> Storagesync mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/storagesync
>>
>

---

From: "Fei Song" <[email-masked]>
Date: Wed, 2 Dec 2015 11:00:20 +0800

--------------
Fei Song

---

From: "Fei Song" <[email-masked]>
Date: Wed, 2 Dec 2015 11:07:15 +0800

Hi Jakub,

I notice that this is a "Special Section", 
any deadline for it? or it will be available for a long time?

--------------
Fei Song
>BTW, here is the public CFP for FGCS: http://cs3.ethz.ch/publications.html
>
>Best regards,
>
>Jakub Moscicki
>
>―
>
>On 26 Nov 2015, at 04:29, Jakub Moscicki <[email-masked]<mailto:[email-masked]>> wrote:
>
>2015-11-26 11:28 GMT+08:00 Fei Song <[email-masked]<mailto:[email-masked]>>:
>BTW, Based on the last sentence of last email:"The intention of this message is to investigate the current state of using WebDAV for sync purposes to see what needs to be improved here and whether we need new protocols"
>
>The outcome he/she wanted might be just the links like http://cs3.ethz.ch/program.html :)
>In another word, I think what I want finally might be a discussion about "What is needed for the ISS: a sync protocol or a generalized API". Sorry for the poor expression : )
>
>I think this is a relevant question indeed (well, actually also if there is any standard needed at all in the first place). By the generalized API do you mean a HTTP-style API (like REST)? In that case you may consider WebDAV quite close and the difference between the protocol and the API blurs for practical purposes.
>
>While I agree that WebDAV may have disadvantages there is a good number of installations using this already in our community (research labs mainly in, but not limited to, Europe). I think the interesting point about WebDAV/HTTP is extensibility and maybe it is worth is that these extensions go by a “standard”. However, you should consider that for reasonably efficient sync scenario the server should also exhibit certain behaviour. That is, in case of owncloud for example, a server should be able to efficiently propagate the ETAG changes up the directory tree (like the Merkle Tree) so that the client may use propfind efficiently. This is not a hard spec requirement but otherwise propfinding the entire remote tree each time would be impractically inefficient. So this really goes a little bit beyond just an API.
>
>You should also consider that the OpenCloudMesh (under GEANT umbrella) is an initiative with the intent is to make cross-service sharing very easy. These shares may also be synchronized automatically. I currently have no evidence, however, that other software providers with the exception of owncloud are interested in developing such standard. If there is no bottom up interest from the users then it won’t happen (in my opinion).
>
>With the link I wanted to point you to the fact that what you discuss in this mailing list will be also discussed at the upcoming CS3 event I linked in. The intent is to do this discussing together between service providers, developers and researchers together ― so that it does not only end up as an academic exercise but backed up by a critical mass if there is some potential in standardisation, at least in our community. I hope this could be of interest to IETF community, as mentioned on the program page.
>
>Selected papers will be published in FGCS after the event, so please stand by, or attend the event if you want to be part of this discussion here. BTW. the abstract submission deadline is past but one exceptionally good contribution could still possibly be accommodated if submitted rapidly.
>
>I would be nonetheless happy to continue contributing to the discussion in this mailing list.
>
>Best regards,
>
>Jakub Moscicki
>
>--
>
>
>Regards,
>Linhui
>
>
>--------------
>Fei Song
>>Hello,
>>
>>What kind of outcome are you looking for with this analysis? Some research in this area has already been done or is being done as we speak
>>
>>e.g. "A study of delta-sync and other optimisation in HTTP/Webdav synchonisation protocols"
>>
>>It would be interesting to see if there is a potential for collaboration. Or maybe we already have some information you are looking for.
>>
>>Best regards,
>>
>>Jakub Moscicki
>>
>>―
>>
>>
>>On 25 Nov 2015, at 11:45, Linhui Sun <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>>Hi all,
>>
>>As I mentioned before, I think the developers could benefit from the IETF standards. The ownCloud (https://owncloud.org/) is just an example. It is developed for those who do not trust commercial storage services and want to build their own network-based storage services. The ownCloud is using WebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV is designed for distributed work but not for the sync. Thus, I made some preliminary investigations on how the ownCloud uses WebDAV for sync purposes. A brief summary of what I've found is in the following, please correct me if I am wrong.
>>
>>I installed the ownCloud server (v8.2.1) on the CentOS7, and the client is a desktop client on Windows.
>>
>>1. To find whether there is a change to the synced directory, the client continuously sends PROPFIND to the server at regular intervals (around 34 seconds under my observation). The server will respond a 207 Multi-Status Response to tell whether the main directory has been changed. To perform this regular check, the client will open a new TCP connection to send the PROPFIND, the server will close the existing TCP connection after responding the 207 Multi-Status Response. For the next check, the client will open another new TCP connection.
>>
>>2. Every time adding (or creating) a new file to the local folder, the client will open a new TCP connection (if there is no connection existing) to send the file asap. The client will first send several PROPFINDs to find out which sub-directory has been changed. And then it sends the file using PUT. The server will respond a 201 Created Response and then terminate the connection. Currently, I haven't found any application layer chunking, all the segmentation are performed by TCP.
>>
>>3. Every time I delete (or rename) a file locally, the client will also open a new TCP connection to send several PROPFINDs to find out which file has been removed (or renamed). Then it will send DELETE (or MOVE). The server will respond a 204 No Content Response (or 201 Created Response) and then terminate the connection.
>>
>>4. I open a file and frequently edit and save it (actually this is what I usually do with the Dropbox). The client will send the whole file to the server every time I save the file.
>>
>>To summarize, it seems that the ownCloud makes heavily use of PROPFIND to achieve the sync process. Each sync operation (e.g. upload, modify and etc.) will start with sending one or more PROPFINDs. And currently, if I add a file to the server (directly from the server side via web interface), the client cannot find the change. I need to interrupt the sync and recover it to make the client be aware of the change and download the newly added file. I'm not sure whether this is caused by the sync mechanism or an improper server configuration. I need to investigate this further and also how the ownCloud works for multiple clients (or devices).
>>
>>For ISS, I think ownCloud has demonstrated to some extent that similar IETF protocols could be deployed and employed. The intention of this message is to investigate the current state of using WebDAV for sync purposes to see what needs to be improved here and whether we need new protocols.
>>
>>Comments are welcome : )
>>
>>Regards,
>>Linhui
>>
>>
>>[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>

---

From: "Fei Song" <[email-masked]>
Date: Fri, 4 Dec 2015 11:52:05 +0800

Here is the latest version. I classified them a bit. Please email me if anything is missed:
 
1.         The design targets of WebDAV, rsync and other existing approaches?
2.         The potential use cases of ISS, such as client/server, git-like pattern, svn, etc.
3.         The efficiency improvements might be the second goal for standardizing ISS protocol
4.         CORS headers on storage sync APIs
5.         What is needed for the ISS: a sync protocol or a generalized API
6.         remoteStorage draft discussion
a)         relationship vs WebDAV
b)         MOVE action should be added or not
c)         synchronization should be considered or not
d)         comics of new standard
7.         GitHub instead of email messages
a)         What is the topic? 
                         i.              Whether it is suitable to build on WebDAV
                       ii.              WebDAV vs remoteStorage
                      iii.              Advantages vs disadvantages of WebDAV

Some related organizations, events, projects, etc.: 
GEANT community, OpenCloudMesh, ownCloud, CS3, remoteStorage, ClawIO, crosscloud, to be added…

---

From: "Fei Song" <[email-masked]>
Date: Sun, 6 Dec 2015 18:25:28 +0800

1.         The design targets of WebDAV, rsync and other existing approaches?
2.         The potential use cases of ISS, such as client/server, git-like pattern, svn, etc.
3.         The efficiency improvements might be the second goal for standardizing ISS protocol
4.         CORS headers on storage sync APIs
5.         What is needed for the ISS: a sync protocol or a generalized API
6.         remoteStorage draft discussion
a)         relationship vs WebDAV
b)         MOVE action (synchronization) should be added or not
c)         Beside web browser, desktop apps (by hacking way)
d)         comics of new standard
e)         etag is mainly for identifying whether a document is changed or not
f)          the distributed peer model (no server) and C/S mode
7.         GitHub instead of email messages (has been created) with following URL:
https://github.com/labkode/Internet-Storage-Sync
a)         What is the topic? 
                         i.              Whether it is suitable to build on WebDAV
                       ii.              WebDAV vs remoteStorage
                      iii.              Advantages vs disadvantages of WebDAV
8.         Metadata and data separation scheme and platform for synchronization
a)         ownCloud when configured to use an Object Storage as the Primary User Storage. (Metadata is handled by a MySQL database)
b)         CERN EOS Storage System. (Metadata is handled in high performance in-memory structures).
c)         DropBox. (As far as I know it uses S3 behind. For metadata it is unknown, but probably not on S3). 
Paper for analyzing DropBox:
http://annasperotto.org/papers/2012/imc140-drago.pdf
d)         ClawIO will have an implementation of this approach in the next phase using Swift.

Some related organizations, events, projects, etc.: 
GEANT community, OpenCloudMesh, ownCloud, CS3, remoteStorage, ClawIO, crosscloud, Dropbox, CERN EOS Storage System,to be added…

---

From: Gihan Dias <[email-masked]>
Date: Sun, 6 Dec 2015 22:29:39 +0530

> Here is the latest version. I classified them a bit. Please email me 
Fei,

Thanks. Looks quite extensive.

Gihan

---

From: "Fei Song" <[email-masked]>
Date: Tue, 8 Dec 2015 12:46:02 +0800

Here is the latest version. Please email me if anything is missing:
 
1.         The design targets of WebDAV, rsync and other existing approaches?
2.         The potential use cases of ISS, such as client/server, git-like pattern, svn, etc.
3.         The efficiency improvements might be the second goal for standardizing ISS protocol
4.         CORS headers on storage sync APIs
5.         What is needed for the ISS: a sync protocol or a generalized API
6.         remoteStorage draft discussion
a)         relationship vs WebDAV
b)         MOVE action (synchronization) should be added or not
c)         Beside web browser, desktop apps (by hacking way)
d)         comics of new standard
e)         etag issues
                         i.              is mainly for identifying whether a document is changed or not
                       ii.              is easy to implement than that of WebDAV sync protocol or not
                      iii.              the metadata file contains all etags for all files at both client and server side or not
f)          the distributed peer model (no server) and C/S mode
g)         a fancy example (with pics) of OfflineIMAP’s sync process in following URL
http://blog.ezyang.com/2012/08/how-offlineimap-works/
7.         GitHub (instead of email messages) has been created:
https://github.com/labkode/Internet-Storage-Sync
a)         What is the topic? 
                         i.              Whether it is suitable to build on WebDAV
                       ii.              WebDAV vs remoteStorage
                      iii.              Advantages vs disadvantages of WebDAV
8.         Metadata and data separation scheme and platform for synchronization
a)         ownCloud when configured to use an Object Storage as the Primary User Storage. (Metadata is handled by a MySQL database)
b)         CERN EOS Storage System. (Metadata is handled in high performance in-memory structures).
c)         DropBox. (As far as I know it uses S3 behind. For metadata it is unknown, but probably not on S3). 
Paper for analyzing DropBox:
http://annasperotto.org/papers/2012/imc140-drago.pdf
d)         ClawIO will have an implementation of this approach in the next phase using Swift.
9.         Whether we should keep metadata history or modification history or action history at server side (or other places)
10.     How to handle the “conflict resolution” issues
a)         A good demonstration of this issue was given in details (File F, Client A, Client B, etc.)
b)         Should it be a layer above syncing
c)         Should it depend on the use case
d)         Should it be a one-size-fits-all approach

---

From: Jakub Moscicki <[email-masked]>
Date: Tue, 8 Dec 2015 06:29:08 +0000

Hello,

Here is the publication schedule (will be updated soon online: http://www.journals.elsevier.com/future-generation-computer-systems/call-for-papers/special-section-cloud-storage-services-file-synchronization/).

Important Dates

Submission Due April 1, 2016
1st Round Notification August 1, 2016
Revision October 1, 2016
Publication (expected) Late 2016 or Early 2017

Best regards,

kuba

—

On 02 Dec 2015, at 04:07, Fei Song <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jakub,

--------------
Fei Song

Best regards,

Jakub Moscicki

―

On 26 Nov 2015, at 04:29, Jakub Moscicki <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

2015-11-26 11:28 GMT+08:00 Fei Song <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>:
BTW, Based on the last sentence of last email:"The intention of this message is to investigate the current state of using WebDAV for sync purposes to see what needs to be improved here and whether we need new protocols"

Best regards,

Jakub Moscicki

--

Regards,
Linhui

--------------
Fei Song
Hello,

Best regards,

Jakub Moscicki

―

Hi all,

Comments are welcome : )

Regards,
Linhui

_______________________________________________
Storagesync mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/storagesync

---

From: "Fei Song" <[email-masked]>
Date: Sat, 12 Dec 2015 22:16:31 +0800

Here is the latest version. Please email me if anything is missed:
 
1.         The design targets of WebDAV, rsync and other existing approaches?
2.         The potential use cases of ISS, such as client/server, git-like pattern, svn, etc.
3.         The efficiency improvements might be the second goal for standardizing ISS protocol
4.         CORS headers on storage sync APIs
5.         What is needed for the ISS: a sync protocol or a generalized API
6.         remoteStorage draft discussion
a)         relationship vs WebDAV
b)         MOVE action (synchronization) should be added or not
c)         Beside web browser, desktop apps (by hacking way)
d)         comics of new standard
e)         etag issues vs metadata
                         i.              is mainly for identifying whether a document is changed or not
                       ii.              is easy to implement than that of WebDAV sync protocol or not
                      iii.              the metadata file contains all etags for all files at both client and server side or not
f)          the distributed peer model (no server) and C/S mode
g)         a fancy example (with pics) of OfflineIMAP’s sync process in following URL
http://blog.ezyang.com/2012/08/how-offlineimap-works/
7.         GitHub (instead of email messages) has been created:
https://github.com/labkode/Internet-Storage-Sync
a)         What is the topic? 
                         i.              Whether it is suitable to build on WebDAV
                       ii.              WebDAV vs remoteStorage
                      iii.              Advantages vs disadvantages of WebDAV
8.         Metadata and data separation scheme and platform for synchronization
a)         ownCloud when configured to use an Object Storage as the Primary User Storage. (Metadata is handled by a MySQL database)
b)         CERN EOS Storage System. (Metadata is handled in high performance in-memory structures).
c)         DropBox. (As far as I know it uses S3 behind. For metadata it is unknown, but probably not on S3). 
Paper for analyzing DropBox:
http://annasperotto.org/papers/2012/imc140-drago.pdf
d)         ClawIO will have an implementation of this approach in the next phase using Swift.
9.         Whether we should keep metadata history or modification history or action history at server side (or other places)
10.     How to handle the “conflict discovery (resolution)” issues
a)         A good demonstration of this issue was given in details (File F, Client A, Client B, etc.)
b)         Should it be a layer above syncing?
c)         Should it depend on the use case?
d)         Should it be a one-size-fits-all approach?
e)         How many different kinds of conflict?
                         i.              File level conflicts, e.g. both remote (server) and local (client) have changed since last sync.
                       ii.              Interleaved level conflicts, e.g. one client makes a change based on version X of the file, a second makes a change based on version X+1, the second one commits, and then the first one commits.
                      iii.              …
f)          The sequence (order) of changes in one file is important or not (quite similar with “item 9” in this list), perhaps depends on the file type (or use cases):
                         i.              It may be important for: sound file, drawing file, latex source files of articles, iWork files, Office files, images, pdfs, source code, etc.
                       ii.              It may be not important for: Physics data.
g)         Whether to enable an automatic merging might be a research problem or a further use case?
h)         If It is so hard to do conflict resolution even for simple and well-structured “vcard case”, should we handle this issue by separating files based on their property?

---

From: "Fei Song" <[email-masked]>
Date: Sat, 12 Dec 2015 22:22:14 +0800

1.The design targets of WebDAV, rsync and other existing approaches?
2.The potential use cases of ISS, such as client/server, git-like pattern, svn, etc.
3.The efficiency improvements might be the second goal for standardizing ISS protocol
4.CORS headers on storage sync APIs
5.What is needed for the ISS: a sync protocol or a generalized API
6.remoteStorage draft discussion
  a)relationship vs WebDAV
  b)MOVE action (synchronization) should be added or not
  c)Beside web browser, desktop apps (by hacking way)
  d)comics of new standard
  e)etag issues vs metadata
    i.is mainly for identifying whether a document is changed or not
    ii.is easy to implement than that of WebDAV sync protocol or not
    iii.the metadata file contains all etags for all files at both client and server side or not
  f)the distributed peer model (no server) and C/S mode
  g)a fancy example (with pics) of OfflineIMAP’s sync process in following URL
    http://blog.ezyang.com/2012/08/how-offlineimap-works/
7.GitHub (instead of email messages) has been created:
  https://github.com/labkode/Internet-Storage-Sync
  a)What is the topic? 
    i.Whether it is suitable to build on WebDAV
    ii.WebDAV vs remoteStorage
    iii.Advantages vs disadvantages of WebDAV
8.Metadata and data separation scheme and platform for synchronization
  a)ownCloud when configured to use an Object Storage as the Primary User Storage. (Metadata is handled by a MySQL database)
  b)CERN EOS Storage System. (Metadata is handled in high performance in-memory structures).
  c)DropBox. (As far as I know it uses S3 behind. For metadata it is unknown, but probably not on S3). 
    Paper for analyzing DropBox:
    http://annasperotto.org/papers/2012/imc140-drago.pdf
  d)ClawIO will have an implementation of this approach in the next phase using Swift.
9.Whether we should keep metadata history or modification history or action history at server side (or other places)
10.How to handle the “conflict discovery (resolution)” issues
  a)A good demonstration of this issue was given in details (File F, Client A, Client B, etc.)
  b)Should it be a layer above syncing?
  c)Should it depend on the use case?
  d)Should it be a one-size-fits-all approach?
  e)How many different kinds of conflict?
    i.File level conflicts, e.g. both remote (server) and local (client) have changed since last sync.
    ii.Interleaved level conflicts, e.g. one client makes a change based on version X of the file, a second makes a change based on version X+1, the second one commits, and then the first one commits.
    iii.…
  f)The sequence (order) of changes in one file is important or not (quite similar with “item 9” in this list), perhaps depends on the file type (or use cases):
    i.It may be important for: sound file, drawing file, latex source files of articles, iWork files, Office files, images, pdfs, source code, etc.
    ii.It may be not important for: Physics data.
  g)Whether to enable an automatic merging might be a research problem or a further use case?
  h)If It is so hard to do conflict resolution even for simple and well-structured “vcard case”, should we handle this issue by separating files based on their property?

---

From: Jakub Moscicki <[email-masked]>
Date: Sun, 13 Dec 2015 07:56:34 +0000

Hello,

You may also consider to add to this list this de-facto sync protocol description used by owncloud sync clients (and some footnote discussion on future development directions):

https://github.com/cernbox/smashbox/blob/master/protocol/protocol.md

This document comes with a test suite (partially implemented) that verifies if a server adheres to this specification.

Best regards,

kuba

--

On 12 Dec 2015, at 15:16, Fei Song <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Fei Song" <[email-masked]>
Date: Mon, 14 Dec 2015 09:50:16 +0800

11.     A de-facto sync protocol description used by ownCloud sync clients (and some footnote discussion on future development directions). This document comes with a test suite (partially implemented) that verifies if a server adheres to this specification. The URL is as follow:

Some related organizations, events, projects, etc.: 
GEANT community, OpenCloudMesh, ownCloud, CS3, remoteStorage, ClawIO, crosscloud, Dropbox, CERN EOS Storage System, to be added…

---

From: "Fei Song" <[email-masked]>
Date: Mon, 14 Dec 2015 09:59:57 +0800

11.A de-facto sync protocol description used by ownCloud sync clients (and some footnote discussion on future development directions). This document comes with a test suite (partially implemented) that verifies if a server adheres to this specification. The URL is as follow:

---

From: "Fei Song" <[email-masked]>
Date: Mon, 14 Dec 2015 10:10:16 +0800

Hi Jakub,

It has been added.
I created a new item for this useful information in the list. Please let me know if you think it should be under other items.
Thanks for that!

--------------
Fei Song

---

From: "Somers-Harris, David | David | OPS" <[email-masked]>
Date: Tue, 29 Dec 2015 14:21:16 +0000

Hi,

Has anybody here heard of Camlistore?
https://camlistore.org/

>From what I gather it's a content agnostic CMS which provides
"... a way to store, sync, share, model and back up content."

Quoting the presenter describing his motivations for writing this: 
"I'm sick of thinking about what the thing is - I just want a place to put stuff"
"I don't really like filesystems, I just want a kind of dumping ground"
"I believe in protocols and standards ... not in companies"
https://www.youtube.com/watch?v=kBCQq5hfsug

There was some discussion in this BOF regarding problems which need to be solved in the content management layer of synchronization.
However, it appears that work has been done already towards solving  some of these problems.
Since it was mentioned in this BOF that we should focus on the transport layer and not so much the application layer, I think that building on top of work like this could be quite appropriate.

I checked the thread and there wasn't any mention of Camlistore so hopefully this is helpful information for people here.
If not, I apologize for the distraction :).

David

---

From: "Fei Song" <[email-masked]>
Date: Wed, 30 Dec 2015 10:31:56 +0800

Not yet...Is it a new one?

--------------
Fei Song