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 PropertyLists,
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.
