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

Reply via email to