For those that don't know what's it about: model XML files
contain code like this:
<model>
<path>test.ac</path>
</model>
* Curtis Olson -- Saturday 13 October 2007:
> [...] I'm not sure why there are strong objections here.
> It's a lot like caching the unoptimized models in a much more
> optimized format.
No. Caching would mean that the file "test.ac" is still the
main source. fgfs would create a "test.osg" from that and use
that, because it's faster. But whenever a "test.ac" was
updated, a new "test.osg" would automatically be made.
In Jim's (committed) version, "test.osg" is always used when
available, while "test.ac" isn't considered *at all*. The
developer explicitly orders "test.ac", but what s/he gets
may be "test.osg". It can be confusing and make debugging
harder. And what if I *want* to *really* try "test.ac" to
see how it compares? I can't, even though it's there. I
have to move "test.osg" away, or rename "test.ac" and its
entry. Sorry, but that's poor design. Not Unix-worthy.
IMHO acceptable is to allow to explicitly leave the decision
to fgfs by just stating the basename: <path>test</path>.
Then fg/plib would just append ".ac" and try, while fg/osg
would first append ".osg", and if it fails ".ac".
Also acceptable would be a fallback mechanism: Try the
path that the developer wanted, and only if not available,
try an alternative.
What Jim proposes is a "fallforward" method: give a damn
about the developer's wish, and just overrule him. May he
want or not. That's the MS Windows way. :-P
m.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
