User:Red Leader/Sandbox/AJAX test: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (Red Leader moved page User:Red Leader/AJAX test to User:Red Leader/Sandbox/AJAX test without leaving a redirect: Better location)
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{caution|AJAX testing in progress.}}
{{FGCquote
  |My long term goal here would be that fg-aircraft goes away, and we actually specify aircraft via their package ID only, with no aircraft-dir set either. But that’s a much bigger step.
(Of course only in a world where all aircraft are run from a package, we still need these options for ad-hoc aircraft and development)
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33699619/
    |title=<nowiki>Re: [Flightgear-devel] Launcher issues on Linux</nowiki>
    |author=<nowiki>James Turner</nowiki>
    |date=<nowiki>2015-04-03</nowiki>
  }}
}}


== Test of AJAX page editing ==
{{FGCquote
  |The dependencies system has never been tried, but the intent is to allow non-aircraft packages of shared resources to be used (i.e common files for all aircraft in a hangar), the question is what option(s) are used to add those packages to the aircraft search list at runtime. Probably the fg-aircraft mechanism is exactly what is needed here.
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33699619/
    |title=<nowiki>Re: [Flightgear-devel] Launcher issues on Linux</nowiki>
    |author=<nowiki>James Turner</nowiki>
    |date=<nowiki>2015-04-03</nowiki>
  }}
}}


This text has been added via AJAX.
{{FGCquote
  |Historically, FlightGear tends to re-invent the wheel more often than not unfortunately - but adopting a package/plugin framework would definitely make sense. While we can certainly proceed without one, the outcome is likely to be hugely incompatible and cause a ton of chaos - once you think about just how many features were/are developed as "addons", some more attention should be given to such considerations and requirements (bombable, advanced weather, fgcamera, tutorials etc)
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=225196#p225196
    |title=<nowiki>Re: How to add sort of addon?  </nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Sat Nov 22</nowiki>
  }}
}}
 
{{FGCquote
  |The question is how far we'd want to go with something like this - because at some point, it would make more sense to adopt an existing [https://en.wikipedia.org/wiki/Package_management_system package management system] that is multi-platform and open source (e.g. [http://sourcey.com/pacm/ pacm] or [http://conda.pydata.org/miniconda.html#miniconda miniconda]). Otherwise, most of the building blocks for a simple package manager are already available to Nasal, i.e. http bindings and SGPath wrappers to download stuff into $FG_HOME and install stuff there. Even though it would probably make sense to also expose zlib (i.e. for extracting compressed archives). Metadata for package names, dependencies, URLs and version/description info could be provided via existing PropertyList XML files. So there's very little missing to pull this off, and a simple prototype for an existing addon, like FGCamera, should be fairly straightforward to build - it's mainly a matter of integrating existing technologies properly, and exposing them first to scripting space.<br/>
But most of the infrastructure is already available, i.e. was implemented for installing aircraft and managing scenery via TerraSync.<br/>
<br/>
And particularly [http://sourcey.com/pacm/ pacm] is looking pretty good actually.<br/>
However, historically, the project tends to "re-invent the wheel" more often than not ...
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=216665#p216665
    |title=<nowiki>Re: Alternative camera control</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Thu Aug 14</nowiki>
  }}
}}
 
=== Test2 ===
This text has also been added via AJAX.

Latest revision as of 14:19, 21 November 2015

Cquote1.png My long term goal here would be that fg-aircraft goes away, and we actually specify aircraft via their package ID only, with no aircraft-dir set either. But that’s a much bigger step.

(Of course only in a world where all aircraft are run from a package, we still need these options for ad-hoc aircraft and development)


— James Turner (2015-04-03). Re: [Flightgear-devel] Launcher issues on Linux.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The dependencies system has never been tried, but the intent is to allow non-aircraft packages of shared resources to be used (i.e common files for all aircraft in a hangar), the question is what option(s) are used to add those packages to the aircraft search list at runtime. Probably the fg-aircraft mechanism is exactly what is needed here.
— James Turner (2015-04-03). Re: [Flightgear-devel] Launcher issues on Linux.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Historically, FlightGear tends to re-invent the wheel more often than not unfortunately - but adopting a package/plugin framework would definitely make sense. While we can certainly proceed without one, the outcome is likely to be hugely incompatible and cause a ton of chaos - once you think about just how many features were/are developed as "addons", some more attention should be given to such considerations and requirements (bombable, advanced weather, fgcamera, tutorials etc)
— Hooray (Sat Nov 22). Re: How to add sort of addon?  .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The question is how far we'd want to go with something like this - because at some point, it would make more sense to adopt an existing package management system that is multi-platform and open source (e.g. pacm or miniconda). Otherwise, most of the building blocks for a simple package manager are already available to Nasal, i.e. http bindings and SGPath wrappers to download stuff into $FG_HOME and install stuff there. Even though it would probably make sense to also expose zlib (i.e. for extracting compressed archives). Metadata for package names, dependencies, URLs and version/description info could be provided via existing PropertyList XML files. So there's very little missing to pull this off, and a simple prototype for an existing addon, like FGCamera, should be fairly straightforward to build - it's mainly a matter of integrating existing technologies properly, and exposing them first to scripting space.

But most of the infrastructure is already available, i.e. was implemented for installing aircraft and managing scenery via TerraSync.

And particularly pacm is looking pretty good actually.
However, historically, the project tends to "re-invent the wheel" more often than not ...


— Hooray (Thu Aug 14). Re: Alternative camera control.
(powered by Instant-Cquotes)
Cquote2.png

Test2

This text has also been added via AJAX.