On 10 Oct 2010, at 17:21, Torsten Dreyer wrote: > Sounds like a good idea. I am working on an extended METAR system > allowing to fetch METAR data for an arbitrary number of stations. This > will allow lateral (not only timed) interpolation of weather. Looks like > these two systems might be a perfect fit.
I'm not keen on this idea, even though I very keen on the concept. My problem is airportinfo() already does *way* too much, and making it do more will not help. 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. I realise that making proper Nasal ghosts for FGPositioned, FGNavRecord, FGRunway, FGAirport is more work, but it would be the right path to putting the Nasal API on parity with the C++ one, and would enable a huge amount of FMS/digital charting/ATC functions to be built in Nasal. If that sounds impossible, then I'd strongly advocate creating separate special purpose-functions in the short term, that do *one* thing, and be more easily subsumed if/when we properly expose the C++ types to Nasal. James ------------------------------------------------------------------------------ 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
