Re: [Flightgear-devel] The future of terrasync

[James T. <zak...@ma...>]

> On 4 May 2016, at 03:05, Curtis Olson <cur...@fl...> wrote:
> 
> My understanding is that the http download method will function very much as before where only the changed files (if any) are downloaded.
> 
> The svn method requires 2x the actual space because of the way svn works under the hood.  Git typically requires that you download every version ever created to get the latest copy (there are work arounds if you just want the most recent version.)
> 
> So the end result for the average user that just wants to download and use the scenery is that the http method will be lighter weight overall.  It also simplifies the code inside FlightGear quite a bit and should make the synchronization more robust.  And as mentioned before, it should simplify the task of setting up a scenery mirror for those that wish to do that.
> 
> As before, power users will have multiple options for updating scenery or mixing and matching from different sources if they choose.
> 

Adding some details to this:

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

Kind regards,
James