On Mon, 2010-10-11 at 09:28 +0100, James Turner wrote:

> On 10 Oct 2010, at 17:21, Torsten Dreyer wrote:
> 


<bits snipped>


> We need to stop exposing *functions* to Nasal, and start exposing *objects*, 
> with properties. 
> 
> Notably, amongst the airportinfo() structure is a runways hash, which 
> contains data that depends on the Airport Scenery data - this means it can 
> trigger the lazy loading of that data, and hence require a disk access. I've 
> noticed the same problem with the map dialog. Most people accessing 
> airportinfo() only want one or two pieces of info, but we compute the whole 
> lot each time.
> 


Yes I'd like to second the idea of returning objects (with attributes
and methods for doing interesting things), I'm guessing we don't need to
abstract it too far from what is provided underneath.

However I really like the idea of getting back an array of airports
within some radius of a centre lat/lon pair, and/or within a bounding
box (2 or 4 lat/lon pairs), and if the same could be done with other
navigation elements in nav.dat it would be most excellent!


S.


------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to