Nl/Terrasync: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 34: Line 34:
</ref>
</ref>


Zoals sommigen van u waarschijnlijk hebben gemerkt, zijn er ontwikkelingen in de terrasync hoek op het gebied van codering, meestal door James en soms door Torsten. De belangrijkste reden is het protocol om landschap te distribueren nuiet meer via SVN te laten plaatsvinden, maar gemakkelijker te implementeren protocollen in te zetten. Het idee is om HTTP te gebruiken als middel om de bestanden te downloaden die terrasync nodig heeft. Dit zou het veel gemakkelijker moeten maken voor "hosts" om een "mirror" in te zetten, het maakt het waarschijnlijk ook mogelijk om een CDN te gebruiken voor load balancing met positieve gevolgen voor de "client".
Zoals sommigen van jullie waarschijnlijk hebben gemerkt, zijn er ontwikkelingen in terrasync gaande op het gebied van codering, meestal door James en soms door Torsten. De belangrijkste reden is het protocol om landschap te distribueren niet meer via SVN te laten plaatsvinden, maar eenvoudiger te implementeren protocollen in te zetten. Het idee is om HTTP te gebruiken als middel om die bestanden te downloaden die terrasync nodig heeft. Dit zou het veel gemakkelijker moeten maken voor "hosts" om een "mirror" in te zetten, het maakt het waarschijnlijk ook mogelijk om een CDN te gebruiken voor load balancing met positieve gevolgen voor de "client".


De bedoeling is om, zodra 2016.1 is uitgebracht, over te stappen op HTTP voor TerraSync (in plaats van SVN), omdat dit veel meer mogelijkheden geeft om de code te verspreiden. De cache bestanden zijn klein en weerspiegelen de revisie van elk bestand in de lokale map; ze zijn vergelijkbaar met de gegevens die een echte SVN client opslaat in zijn svn' directory in de root-file. Ik verwacht dat de zuivere HTTP-oplossing enkele gelijkaardige bestanden nodig heeft om de HTTP cache-blokken van bestanden die het downloadt op te slaan - één bestand in de hoofdmap van de structuur of per directory. (Er zijn voordelen en nadelen voor beide.) <ref>{{cite web
De bedoeling is om, zodra 2016.1 is uitgebracht, over te stappen op HTTP voor TerraSync (in plaats van SVN), ervan uitgaande dat dit ook veel meer mogelijkheden geeft om de code te verspreiden. De cache bestanden zijn klein en weerspiegelen de revisie van elk bestand in de lokale map; ze zijn vergelijkbaar met de gegevens die een echte SVN client opslaat in zijn svn' directory in de root-file. Ik verwacht dat de zuivere HTTP-oplossing enkele gelijkaardige bestanden nodig heeft om de HTTP cache-blokken van bestanden die het downloadt op te slaan - één bestand in de hoofdmap van de structuur of per directory. (Er zijn voordelen en nadelen voor beide.) <ref>{{cite web
   |url    = https://sourceforge.net/p/flightgear/mailman/message/34767003/
   |url    = https://sourceforge.net/p/flightgear/mailman/message/34767003/
   |title  = <nowiki>Re: [Flightgear-devel] Launcher changes for 3.8</nowiki>
   |title  = <nowiki>Re: [Flightgear-devel] Launcher changes for 3.8</nowiki>
539

edits

Navigation menu