Talk:Canvas ND framework: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Created page with "really "744" or is that a repeated typo and you mean "747" ? ~~~~")
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
really "744" or is that a repeated typo and you mean "747" ? [[User:Laserman|Laserman]] ([[User talk:Laserman|talk]]) 17:55, 30 November 2013 (UTC)
== Versioning ==
As more and more aircraft start adopting the framework, we should consider adding some "versioning" support, so that people can request a certain version and assume a certain API that won't change over time. TheTom is already doing this in the Canvas APIs - and we  basically need a similar mechanism, so that the APIs can evolve, without breaking unmaintained aircraft - redneck and omega95 were extremely frustrated with the lack of backwards compatibility when the route manager/fplan APIs were reworked, because they didn't have the time to update their aircraft - so this is a valid point and we should make sure that we're not causing any unnecessary frustration here. I am proposing a hash/namespace-based lookup for APIs, unless Philosopher can convince me that we need something more sophisticated than that...
 
<syntaxhighlight lang="nasal">
 
var VersionedAPIContainer = {};
VersionedAPIContainer.new = func(version);
...
 
 
var NavDisplay = {};
NavDisplay[ "1.0" ] = VersioonedAPIContainer.new( "1.0" );
 
...
 
# request a certain API version
var ND = NavDisplay["1.0"];
ND.new();
 
 
 
</syntaxhighlight>
 
it may make sense to come up with a generic framework for API versioning (possibly by looking at Tom's work) and using the same approach to also support versioning at the MapStructure level itself. Ideally, multiple instances of different versions could co-exist without issues.
 
{{unsigned|21:39–21:41, 30 January 2014|Hooray}}
 
== Generic integration instructions (wip) ==
 
See [[Template:Canvas ND Integration Tutorial]]

Revision as of 10:53, 1 October 2016

Versioning

As more and more aircraft start adopting the framework, we should consider adding some "versioning" support, so that people can request a certain version and assume a certain API that won't change over time. TheTom is already doing this in the Canvas APIs - and we basically need a similar mechanism, so that the APIs can evolve, without breaking unmaintained aircraft - redneck and omega95 were extremely frustrated with the lack of backwards compatibility when the route manager/fplan APIs were reworked, because they didn't have the time to update their aircraft - so this is a valid point and we should make sure that we're not causing any unnecessary frustration here. I am proposing a hash/namespace-based lookup for APIs, unless Philosopher can convince me that we need something more sophisticated than that...

var VersionedAPIContainer = {};
VersionedAPIContainer.new = func(version);
...


var NavDisplay = {};
NavDisplay[ "1.0" ] = VersioonedAPIContainer.new( "1.0" );

...

# request a certain API version
var ND = NavDisplay["1.0"];
ND.new();

it may make sense to come up with a generic framework for API versioning (possibly by looking at Tom's work) and using the same approach to also support versioning at the MapStructure level itself. Ideally, multiple instances of different versions could co-exist without issues.

This unsigned comment was added by Hooray (Talk | contribs) 21:39–21:41, 30 January 2014 (UTC)

Generic integration instructions (wip)

See Template:Canvas ND Integration Tutorial