I kind of feel like I'm stepping into an exploding land mine even trying to
reply to this thread, but so be it...
I haven't tracked this discussion or proposal down to it's finest level of
detail, but I'll still make some comments. :-)
- Melchior, I think you might be a little overly dramatic here. This
doesn't nearly rise to the level of bad programming like if you ran across a
fixed array size used to hold a list of items that will likely grow in the
future, or any other number of things that are usually bad ideas. However,
I do very much appreciate your intense commitment to keeping the FlightGear
design, code, file layout, etc. clean and neat and well conceived.
- Upon looking at the proposals, both Martin's and Melchior's schemes ought
to technically work just as well as each other's ... give or take a few
bytes here and there burned in the directory listings and possibly some
aesthetics depending on your perspective, which doesn't amount to the end of
the world either way in my view.
- If it was me doing this, I would suggest something like:
Airports/L/LO/LOX/LOXA.xml (just the one file per airport)
Is there a reason that we split up each airport's data into at least 5
different files? XML is really good at structuring and segmenting data ...
could we not just put all the airport data into one file? That seems *MUCH*
cleaner to me. There's probably an issue of different sections of the code
wanting to access different portions of the data which is why it's split up,
but having many different sections of the code uniquely accessing different
files from this tree is messy in and of itself. Having a single airport
data manager class or interface would seem like a nice clean design concept
... that way whatever directory scheme we come up with doesn't have to be
replicated in many places in our code.
Right now, Martin's proposal uses path/file <dot> extension <dot> another
extension. That is the main thing that jumps out at me as being
unappealing. And perhaps that is at the root of Martin's gripes, although
not verbalized in exactly that way.
I actually don't like Melchior's proposal all that much either because now
you have 20,000+ files called ils.xml on your hard drive and 20,000+
parking.xml files, even though they are in unique directory paths.
Something about that is unappealing to me too.
One issue to consider is that on windows file systems, the minimum block
size is usually really big, so tons of little files really burns up and
wasted disk space. (Not sure about modern NTFS file system, but
historically this has been an issue.) On linux ext2/ext3 there is a limit
to the number of inodes (total number of directories and files that a file
system can hold and reference.) This is set when the file system is created
and can't be extended later (other file systems are more flexible, but let's
not get side tracked on file system advocacy!) :-)
So my point would be that avoiding a new explosion in number of small files
is another worthy design goal.
Best regards,
Curt.
On Mon, Nov 3, 2008 at 2:09 AM, 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)
> - natural grouping done by prefixes, rather than directories (the latter
> of which were invented for that purpose and come at *no* costs)
> - tower abbreviated as twr (not saving *any* space)
>
> Technical argument:
> - "it's too late, we don't want to change it anymore"
>
>
>
>
> 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
> - consistent and logical: all ICAO/ID letters are treated the same way
> - easy path creation e.g. in Nasal
>
>
>
> 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. :-)
>
> m.
>
> -------------------------------------------------------------------------
> 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-users mailing list
> Flightgear-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-users
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
-------------------------------------------------------------------------
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-users mailing list
Flightgear-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-users
