TerraSync: Difference between revisions

Jump to navigation Jump to search
1,658 bytes added ,  4 May 2016
Line 28: Line 28:
   |author = <nowiki>James Turner</nowiki>
   |author = <nowiki>James Turner</nowiki>
   |date  = Jan 14th, 2016
   |date  = Jan 14th, 2016
  |added  = May 4th, 2016
  |script_version = 0.31
  }}
</ref>
* supporting the various possible backends inside the code is a headache, so the intention is to support /only/ the HTTP method inside FlightGear directly, aka ‘built-in terrasync’
* one of the major benefits of the HTTP system, is that is uses SHA1 hashes instead of SVN revisions, to identify files, and there is no base (server) URL stored inside the downloaded directories. This means you can prep a terrasync directory with files downloaded by any mechanism you like (DVD, BitTorrent, copying from another machine) and providing the SHA1 hashes match, the files will not be download again. Any files which are out of date will be refreshed, but only those files. This also means switching from SVN -> HTTP does /not/ download everything again.
Switching servers, even within the same FG session, is also possible and again does not result in any re-downloads, unlike the SVN setup where the server URL is part of the repository structure.
* the terrasync /network protocol/ will remain, which means you can write (in a wide ranges of languages, including Python) your own external terrasync engine, using rsync or any other mechanism you like. My hope is this provides a good and maintainable extension point for very advanced users, while the built-in HTTP mechanism will be be simple and robust (thanks to be being hash-based) for 95% of users.<ref>{{cite web
  |url    = https://sourceforge.net/p/flightgear/mailman/message/35064352/
  |title  = <nowiki>Re: [Flightgear-devel] The future of terrasync</nowiki>
  |author = <nowiki>James Turner</nowiki>
  |date  = May 4th, 2016
   |added  = May 4th, 2016
   |added  = May 4th, 2016
   |script_version = 0.31
   |script_version = 0.31

Navigation menu