Re: [Flightgear-devel] [Flightgear-users] Proved and maintainable methods

[Durk T. <d.t...@xs...>]

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/fli...@li.../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.