Tony Peden writes:

 > This also brings up the recurring question regarding the use of a
 > third-party XML parser.  For once, I'll have to side with keeping
 > our own, since that would allow us to change the config file over
 > in phases rather that all at once.

There's another alternative.  Currently, each component knows how to
parse its own section of the config file -- the gear module parses
gear data, the thruster module parses thruster data, etc.  We could
start developing a new parser that constructs objects entirely
externally, setting information with public getters and setters.  When
it's working well enough, we can simply remove the old, internal
code.  Converting the actual config files to the new format is a
trivial job (half an hour, a good mug of hot chocolate, and XEmacs
regexp support will do the trick).

There are very small, well-debugged XML parser libraries available (we
use Expat in FlightGear), and it would be nice to take advantage of
one.  We could leave the current parsing code in place and untouched
until we're 99.999% certain that the new parser is working correctly.


All the best,


David

-- 
David Megginson
[EMAIL PROTECTED]


_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to