Hi Melchior, why do you take this to the -users list again, where it is obviously off-topic as a development issue and after I had taken the discussion where it belongs: to the -devel list?
The proposal as posted in my announcement was designed by a group of developers, not just Martin and me. I just took the task of proposing and defending it. You might want to consider that the proposal was thoroughly pondered before implementing it on the scenery side and publishing it. Our team has experts on the relevant issues, ranging from databases and operating systems to the concerned parts of FlightGear and the scenery process. So as long as you do not _prove_ us wrong, there is no reason to conclude that our proposal is nonsensical. I will show that what you did is far from proving us wrong. I am open to change the structure and even defend the change in the group of developers who have designed it if the change does not contradict the goal of the proposal and there are sufficient arguments for a change weighing up the cost of additional risk and effort. Not only are your arguments not sufficient, the largest share of your change requests even contradicts the goal of our proposal. For the benefit of discussion with _other_ FlightGear developers I will lay out the arguments for this. I might add that in some rare cases I share your sense of beauty w.r.t. technical aspects of FlightGear, but this is not such a case and even if it was, it would not be a sufficient argument. I am full-quoting your mail, so all developers not on the users-list can see what we are talking about. That should be also in your interest, because your and my comments can now be found in additional places, so you and I can occasionally point to it ;-) Melchior FRANZ wrote: > I give up. Let's just have the nonsensical directory layout. > It's not the only bad design in fgfs, and I'm the only one > who cares about it, anyway. But here's a final comparison > for your entertainment (and for the archive, so that I can > occasionally point to it ;-): > > Solution 1 -- proposed and defended by Ralf and Martin: > ------------------------------------------------------- > Airports/L/O/X/LOXA.ils.xml > /LOXA.parking.xml > /LOXA.rwyuse.xml > /LOXA.twr.xml > /LOXA.threshold.xml > /LOXN.ils.xml > /LOXN.parking.xml > /LOXN.rwyuse.xml > /LOXN.twr.xml > /LOXN.threshold.xml > /LOXT.ils.xml > /LOXT.parking.xml > /LOXT.rwyuse.xml > /LOXT.twr.xml > /LOXT.threshold.xml > /LOXZ.ils.xml > /LOXZ.parking.xml > /LOXZ.rwyuse.xml > /LOXZ.twr.xml > /LOXZ.threshold.xml > > Characteristics: > - lots of files per level (messy) "lots of files per level" is the characteristics. "lots" is not a quantifiable measurement and "messy" is your very personal interpretation. Incidentally, "messy" is the only attribute in this point I can see coming near to an argument against our proposal, again in the realm of personal perception of beauty and therefore without any concrete foundation except your personal taste. Your personal taste is not in itself a sufficient argument for a change in this context. I think we should rather be discussing concrete characteristics such as validity, maintainability, performance and correctness. Wouldn't you agree? > - natural grouping done by prefixes, rather than directories (the latter > of which were invented for that purpose and come at *no* costs) Just because it might not cost anything doesn't mean that it's better. Window paint was invented for the purpose of painting windows and comes at no recurring cost. Still it does not make any sense to me to paint my windows if I want to have an unobstructed outside view. Also the fourth directory level _does_ cost something. See below. > - tower abbreviated as twr (not saving *any* space) Saving space might not be the only argument in favour of "twr", and even without such an argument, I can see no important point against our proposal here that would warrant a change. > Technical argument: > - "it's too late, we don't want to change it anymore" You might want to check your use of quotes, because they usually indicate word-by-word quotations. Neither can I be quoted that way nor did I say anything that implies the meaning of the phrase attributed to me. This is what I wrote: > So if there is a strong argument in favour of the changes you proposed, > I'm open to such a last-minute change, but otherwise I'd rather leave > the structure as it is. (http://sourceforge.net/mailarchive/message.php?msg_name=490CA168.40004%40custom-scenery.org) This was the very first time I mentioned this constraint and did not represent it differently afterwards. Further what you obvioulsy are referring to was not a technical argument, but of organisational nature, without the implication that there are no technical arguments. So your summary is incomplete and misrepresenting my argument. Melchior FRANZ wrote: > Solution 2 -- proposed by /me: > ------------------------------ > > Airports/L/O/X/A/ils.xml > parking.xml > rwyuse.xml > tower.xml > threshold.xml > Airports/L/O/X/N/ils.xml > parking.xml > rwyuse.xml > tower.xml > threshold.xml > Airports/L/O/X/T/ils.xml > parking.xml > rwyuse.xml > tower.xml > threshold.xml > Airports/L/O/X/Z/ils.xml > parking.xml > rwyuse.xml > tower.xml > threshold.xml > > > Characteristics *and* technical arguments: > - directory per airport for natural grouping and clear layout The assumption of validity of this argument in favour of your proposal is based on the false assumption that a clear layout in the form you want it would actually contribute to fulfilling the intent of the structure proposed by us. This is not the case, to the contrary. > - consistent and logical: all ICAO/ID letters are treated the same way Yes, your approach is consistent and it is logical _in this point_. But still our approach is neither inconsistent nor illogical _in the whole_, nor is yours logical and consistent _in the whole_. "consistency" in the form requested by you contradicts the intent of the proposal, but not because we'd want inconsistency. > - easy path creation e.g. in Nasal However, "easy path creation" wasn't the goal of the structure. An even easier path would have been "Airports/KSFO/*.xml" or "Airports/KSFO.xml", but that would have contradicted the intent. The intention was to create a poor-man's-index, relieving filesystems of having to search through a directory with files for about 22k Airports, which often happens in a naive way with O(n) runtime complexity. The division of the information so that each file contains information about only one airport was necessary to allow distribution of only those airports with a scenery tile which are actually contained in the tile. The index concept has some similarity to a B-tree (http://en.wikipedia.org/wiki/B-Tree) in terms of structure, though the balancing aspect and therefore some of the performance estimates do of course not apply. Still, the general intention and the structural aspects are in most points applicable to our index. There is a point at which the index-partitioning becomes excessive and doesn't bring any notable benefit in terms of the intent. This point is reached after the third level in this case. Otherwise we'd have a lot of directories with just a few files. In most there would even be just one file, which is threshold.xml. This would be similar to a single entry in a leaf node of a B-Tree, which for several reasons is not allowed, except if the leaf is the root of the tree at the same time. In terms of size this would even mean that in many if not most filesystems we'd have an additional directory using up an additional block of the underlying block device just to store the meta-information about a single file. We'd have an additional block to be loaded just for finding that single file. This would most probably not be weighed up by the benefit introduced by reducing the number of airports files in the last directory level. So in addition to not bringing any benefit, the additional level would also introduce additional recurring cost, contradictory to your assertion. So this reduces it all to combining the files of one airport into one file, which we already discussed and dismissed for reasons of differing sources of information and which you did not propose in your "final" comparison anymore. Even this wouldn't solve your path-creation-issue, because we'd still have a three-level directory structure. I'd like to add that "TWR" - like "RWY", which is used in "rwyuse.xml" and which you have reused in your proposal above instead of e.g. "runwayuse.xml" -, is a perfectly accepted and well-known abbreviation in aviation. "ILS" or "GND" belong in this category as well. So for me as a real-life aviator, twr.xml is actually beautiful. Again: Not that beauty would mean anything in this context and not that the naming is actually relevant for the structure. To conclude: Part of your proposal does contradict the intent of the structure. In the places where it doesn't - only the names of the XML-files -, your proposal is not superior to ours and the arguments for a change are therefore not sufficient. Therefore no change towards your proposal in your "final comparison" is warranted. I also see no further benefit or reason in letting myself being mocked or talked down upon by you, so the discussion of us two about this proposal ends at this point. However, if anyone else has comments or criticism on the proposal, I'd like to hear about them. > Or maybe we should use prefixes instead of directories at other > occasions as well, if that concept is considered superior. > Let's see: > > $FG_ROOT/Aircraft/bo105.splash.rgb > $FG_ROOT/Aircraft/bo105.thumbnail.rgb > $FG_ROOT/Aircraft/bo105.fdm.xml > $FG_ROOT/Aircraft/b1900d.splash.rgb > $FG_ROOT/Aircraft/b1900d.thumbnail.rgb > $FG_ROOT/Aircraft/b1900d.fdm.xml > $FG_ROOT/Aircraft/concorde.splash.rgb > $FG_ROOT/Aircraft/concorde.thumbnail.rgb > $FG_ROOT/Aircraft/concorde.fdm.x ml > > Yummy. :-) Probably not more to add but proposing the following layout instead: $FG_ROOT/Aircraft/b/o/1/0/5/splash.rgb $FG_ROOT/Aircraft/b/o/1/0/5/thumbnail.rgb $FG_ROOT/Aircraft/b/o/1/0/5/fdm.xml $FG_ROOT/Aircraft/b/1/9/0/0/d/splash.rgb $FG_ROOT/Aircraft/b/1/9/0/0/d/thumbnail.rgb $FG_ROOT/Aircraft/b/1/9/0/0/d/fdm.xml $FG_ROOT/Aircraft/c/o/n/c/o/r/d/e/splash.rgb $FG_ROOT/Aircraft/c/o/n/c/o/r/d/e/thumbnail.rgb $FG_ROOT/Aircraft/c/o/n/c/o/r/d/e/fdm.xml Different goals, different solutions ;-) > m. Cheers, Ralf -- Ralf Gerlich | World Custom Scenery Project Computer Scientist | http://www.custom-scenery.org/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
