Loading...
 

Why Syncthing

Why was Syncthing picked over the many alternatives?

Context

Please see: Files vs web pages. In the context of WikiSuite, we already have file management

  • Tiki File Galleries, which provide virtual folders and sub-folders which are web accessible. This abstraction layer permits multiple features: archives (previous versions of a file can still be accessed), check-in / check-out / lock, etc. and it leverages Tiki's multitude of built-in features: search (including file content), share secret link to file via email, permissions, etc. It's even possible to use as a field type in Tiki Trackers, a powerful and flexible database, form and report creator.
    • WebDAV permits to edit files as if they were on your desktop (avoiding the need to download files, edit them locally, and re-upload). However, it's not suitable when you have a set of files generated by an external system or that need to maintain internal links. Please see enhancement being planned: https://dev.tiki.org/File-Gallery-direct-file-mapping-mode


Even with all these features, one important one was missing: the capability to sync between Tiki and devices (laptop or mobile phone). Thus, an extensive analysis of all available Free / Libre / Open Source software was conducted, and Syncthing was deemed the best component to complete the feature set. Here is the plan: Syncthing in WikiSuite

Beyond satisfying the usual component criteria, Syncthing's P2P design is awesome.

Why not ownCloud / Nextcloud

  • Way too much overlap between Tiki Wiki CMS Groupware and ownCloud / Nextcloud. It's way less work to add / improve any missing functionality in Tiki than to deal with overlap.
  • The server and clients are different code bases, which is bigger long term workload.
  • Can't do P2P sync. Everything needs to go via central server.



Why not Seafile

  • Seafile is an interesting project but
    • Way too much overlap between Tiki Wiki CMS Groupware and Seafile. It's way less work to add / improve any missing functionality in Tiki than to deal with overlap.
    • The server and clients are different code bases, which is bigger long term workload.
    • Can't do P2P sync. Everything needs to go via central server.


Why not Pydio

  • Pydio is an interesting project but
    • Way too much overlap between Tiki Wiki CMS Groupware and Pydio. It's way less work to add / improve any missing functionality in Tiki than to deal with overlap.
    • The server and clients are different code bases, which is bigger long term workload.
    • Can't do P2P sync. Everything needs to go via central server.


Why not SparkleShare

  • SparkleShare is an interesting project but
    • Way too much overlap between Tiki Wiki CMS Groupware and SparkleShare. It's way less work to add / improve any missing functionality in Tiki than to deal with overlap.
    • It's based on Git whereas Syncthing uses the Block Exchange Protocol which is more suited for this use case
    • Can't do P2P sync. Everything needs to go via central server.


Why not LinShare

  • LinShare is an interesting project but it is for file sharing and not file sync. File sharing is covered by Tiki file galleries


Why not Rsync

  • Rsync is a command line tool (although there are some GUIs available)
  • Rsync is to sync 2 directories. There is no 3 way sync and it can't deal with device discovery like Syncthing can.


Why not Unison

Unison is an interesting option, but compared to Syncthing:

  • No Android support
  • No device discovery



https://github.com/bcpierce00/unison

Why not Retroshare

Retroshare is a very interesting. You should definitely check it out.

In terms of files, it offers "file sharing" but this is to disseminate files to your contacts in serverless way. It is not designed to sync files between devices (and thus collaboration).


http://retroshare.net/

See also