On 09/16/09 01:22, James Turner wrote: > My point is, what I'm going to do first, is improve the > *architecture*, so the policy is explicit (and centralised!).
Sounds good to me! > Likely > this will include a Nasal interface (to be driven from a GUI dialog / > ATC-controller / whatever) Sounds good. Most parts of FGFS do a respectable job of keeping high level policy decisions out of the low level code. Perhaps this is why the exceptions stick out like sore thumbs. Exceptions include: -- The decision of when to reverse a reversible ILS really does not belong in navradio.cxx -- My favorite is the decision of when to turn on the runway lights, approach lights, et cetera. The last time I looked, this was in a very low-level routine -- a /library/ routine -- which is far from where it belongs. Short of re-architecting this bit of code, there is no way to implement any sane policy about daytime IMC lighting, active/inactive runway lighting, pilot-controlled lighting, etc., not to mention MP issues. > and I even have some ideas about > synchronising the state across MP. Wow. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
