Hi, I agree with those who are against the proposed new vector format even though I like Tim's basic idea that improves vector calculation performance.
As Melchior alrwady said, the new format has nothing to do with what Tim really wants (performance improvement). A node with 3 or 4 float numbers can be converted into a vector class internally in C++ code without the new vector format inside an XML tag. Moreover, the new vector format doesn't improve the usability at all. a user-defined text format inside an XML tag is not recommended since it decreases the readability unless you give a comment, which is way not better than using tags. If we really need more concise format that improves usability, then we need to throw away our current xml files and make new files in our own new format, which I believe is nonsense. The new format also needs a parser, property browser changes, and converter(s) that don't help us improve any usability or performance at runtime, I guess. If such new format gives us some usability or performance improvement, I can accept it even if some extra work is required, but this is not the case. The JSBSim's table format, which I believe, also lacks the readability. It ,however, gives aircraft developers some usability like easier to copy and paste some table data from external tools like javaprop or excel. I know some helper script can create a well- formatted XML tags, but it could be true that many aircraft developers like simple copy-paste things while tweeking prop/engine things tons of times a day. Nevertheless to say, these tables don't need converters or browser changes since these are only read at launch time, and are not readable from the property browser or telnet. So comparing JSBSim table and the vector format doesn't seems fair to me. I hope many people understands what Melchior said on the property system. His "going home" thing didn't mean that he just wants to hide away unless his opinion is accepted, but he wanted to say the proposed vector format is that bad in terms of software architecture. He might be sometimes brutal in his written words, but I really like his software architecture related comments. These are almost always right, at least to me. I don't say anything on his other comments though :-p Tat p.s. I've moved and my network connection is limit only to iphone until at the end of this month. Sorry for my veeeery slow response, especially to Mac users. ----- Tatsuhiro Nishioka On 2009/04/06, at 5:33, Erik Hofman <e...@ehofman.com> wrote: > Curtis Olson wrote: >> This isn't an argument for or against Tim's proposal in and of >> itself, >> but it's at least interesting to observe other real world cases that >> are at least partially similar. Has JSBSim run into any problems >> with >> it's journey down this path? > This has been one reason why I have been cautious about including it, > this setup does tend to result more errors than laying it down is > separate xml nodes. Also, the JSBSim configuration files are often > generated by a script (aeromatic in this case) first and then altered. > This minimizes human error. > > That said, it looks to me the best way to eliminate all concerns is to > make sure that subsystems that are going to use array-properties use a > detached property tree (not attached to the root tree as shown in the > property manager). It looks to me that would be no problem for the > shader subsystem since it (like JSBSim) only uses the property tree to > read the configuration file. After it has been read there would > probable > little or no need to adjust the individual properties using the > property > manager, or to send them over the network, anyhow. > > Erik > > --- > --- > --- > --------------------------------------------------------------------- > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel