> I'd embed the parser right in JSBSim rather than requiring an > external library. The C source files for Expat are under 300K, so > they wouldn't make much of a difference in the distro size.
Well, I am talking about getting everything we want from JSBSim CVS. I would not think we'd want to store any parser code in JSBSim CVS. Also, JSBSim source code right now stands at about 680K. An additional 300K is nearly half the size of our current source code set. Adding another whole set of code is not an appealing option. > It's wise to avoid rolling your own, lightly-tested, potentially-buggy > when there's free, stable, well-tested and well-documented code out > there. None of us is writing our own printf or TCP/IP stack these > days, no matter how AR we are -- I suggest that an XML parser is the > same nature of beast. printf() is part of a standard library which we expect to be present in any C++ distribution we'd compile with. It's a requirement. It's a convention. It would be nice if there was a standard XML parsing library that was required to be on any platform we'd compile under: Mac, Linux, IRIX, Windows, MSVC, Borland, CygWin, etc. I don't think there is. Also, I'd hardly say FGConfigFile is lightly tested. It might not be perfect, but I have spent as much time testing that class as with any of them, and what it does, it does well, if not everything we'd want it to, but that's our fault in design. We could initially have set out to write a config file in a basic flat file text format. Perhaps that would have been simpler, but probably XML buys us something - though I am not sure what, yet, given our specific and limited purpose. As for potentially buggy code, if a bug does crop up in someone else's code I don't want to hammer through 300K of someone else's bad code to figure out where we have been throttled - waddling through my own bad code is bad enough. In our case, I think the wisest choice is the path we have taken - though I readily accept there are likely others who disagree with me on that one. > I'm not suggesting that you start using data-content notations, > external entities, etc., any more than FlightGear is forced to use the > more esoteric parts of OpenGL. The format can be as simple as you > like, though I think that Tony's right that it's time to make the > tagging more granular. I have thought about that for some time - partially because the free XML Notepad (an MS free download) is hard to work with in our semi free-form config files. The current config file format is understood, but not formatted nicely. Also, I like the idea about defaults, etc. > Look at it this way -- college students can walk into Borders and buy > dozens of books about XML at all level of difficulties. They've > probably learned XML in their computer courses, they read about it in > computer magazines, they can visit hundreds of XML-oriented Web sites, > and there are XML-aware people on campus who can help them with it. > None of that is true of the custom JSBSim XML-like format, so you're > actually putting them at a disadvantage by not using XML (just as you > would be by using SI units when most of the textbooks use Imperial). I disagree. College students *can* certainly walk into a bookstore and buy an XML book. But, would they? Aero students? No. Not aero students. C++ is becoming more standard now in pretty much all aero programs I am aware of - or at least it is a highly recommended elective. XML is not on their menu. Armed with a knowledge of C++, they won't need to know anything else other than what they are studying to understand and use JSBSim. The aero concepts they are studying will be very helpful and they will see them in practice. Those with an interest in simulation and/or using simulations for study and analysis should find JSBSim (and the code itself) self explanatory. I am reluctant to add another layer of complexity unrelated to the engineering task at hand. Jon _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
