On Friday 02 May 2008 13:07, Melchior FRANZ wrote: > * Durk Talsma -- Friday 02 May 2008: > > Melchior is suggesting I should have used a different method for > > parsing the traffic files. :-) > > I'm stating that, not just suggesting. :-P > > The refusal to use the standard ways is IMHO bad for FlightGear. > This shouldn't have passed code review. Had you used <PropertyList>s, > with proper geo coords (not the very unpractical "S37 37.103" format), > then we could easily load a parking.xml file into FlightGear, edit > the slots there in UFO mode, and save the file again. We are limiting > our possibilities by disregarding consistency. It always bites us > in the butt later. >
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13600.html "refusal" seems a rather unfortunate choice of words here. :-) BTW, reading your message, I noticed a considerable distortion of facts.You make it seem as if I deliberately refused to comply with a standard. However, that has never been an issue, because the groundnet parser predates most of the more advanced UFO based editing facilities. Please look at this from a historic perspective and reconsider what you've just said: At the time I implemented the parser, in 2004, we had no parking or AI network editing capabilities whatsoever, except for a windows program called afcad, which was used to develop airport layouts for FS2004. This program allowed me to create some parking data, and export it to XML. The particular XML format is fairly close to the one we have now, only it didn't include AINodes, and AIArcs, just parkings. Now, what would have been the more logical choice at the time: Working toward support for the only limited editor I had access to, or work toward support for no editor at all? Just like FDMs, which also have their own parser, the AINetwork data were intended for internal use, and never designed to be shared by external applications by means of the property system. Had the latter been the case, this would have been a good argument. At the time, it was not an issue, however. It wasn't until two years after the ground network code had been established (around April 2006) that you came up with the idea of of using the UFO to edit the ground network. Then, you found out the format of the xml file was not to your liking. That being the case, a reasonable course of action could have been to request a change to a format more suited to your needs, which we could have discussed and agreed upon. Apparently frustrated, you started bashing away immediately instead, publicly denouncing the format in question being the result of a "Braindead" decision. While I have indicated, on previous occasions, of being open to the idea of changing the parking files to a new format, I'm trying to schedule this appropriately on my TODO list. Admittedly, being able to use the UFO for ground network using the UFO has some limited appeal, but is this really something that we seriously want to persue? I don't think so. Ground network editing is best performed in taxidraw, where we not only have a dedicated program for editing routing information, matching it to the taxiway, etc, but where we also have a platform for implementing a solid set of ground net verification functions, that would be way too intensive to be implemented in nasal in a real-time application. In other words, I'm still not convinced that an immediate rewrite of the ground network xml format is the most appropriate use of my limited resources. I have no reason to assume that my ground network file format was in violation of any project policy at the the time. Therefore, I feel justified in defending it, as I also believe the code reviewer / committer was correct in allowing the code for the parsers to go in. In hindsight it is very easy to criticize the format for not being able to do something we never considered possible in the first place, but that is after the fact, and therefore not justified. I therefore assume that your comments strictly reflect your personal views, and not an official flightgear policy. However, should I find that other developers have equally strong opinions about this issue, I am willing to change my mind. I am willing to move the overhaul one notch up on my TODO list for every developer who voices his agreement here. So if this is really an issue that lives among developers then it should be addressed very soon. However, if it turns out that the overhaul is mainly driven by your desire to get the UFO based network editing going than it's not going to happen until after I've tackled more pressing issues. Of course, there's a golden rule in open source land: If you want something changed, you can always do it yourself. Please consider updating taxidraw as well, while you're at it. :-) Cheers, Durk P.S., I'm moving this thread over to the developers list, where it really belongs. D. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
