On Tuesday 23 November 2004 00:06, Boris Koenig wrote: > Lee Elliott wrote: > > The downside would be that an installer/un-installer would > > become a necessity. > > I think that issue was discussed some time ago on the user > list ? > > Probably, it would already be sufficient to simply package > aircraft folders as tar archives in order to simplify > installation ? > > If I am not wrong, FlightGear is already linked to libz.a - so > basically it supports already dealing with compressed files, > at least that's exactly what FlightGear is doing with the > navaids database under $FG_ROOT/Navaids. > > So, it would be pretty straight forward to simply open an > archive, look for a specific XML file that describes the > aircraft/contents or rather look for the corresponding tags > within an XML file such as *-set.xml and display the > encountered information, so that the user can choose whether > to install (=extract all its contents to a specific location) > the (aircraft) archive or not. > > Actually keeping track of aircraft that are installed in > non-standard locations (!=$FG_ROOT/Aircraft) would indeed > require some kind of list with those locations that are > already in use, so that FlightGear can also check for > available aircraft there. > > Uninstalling is of course a whole different matter, at least > taking into account that Aircrafts can theoretically have > cross-references to other Aircraft's components - so one would > want to preserve such dependencies... > > That's where RPM comes in ;-) > > > At a minimum, only the paths need be stored, together with > > the classification tags, but who could resist the temptation > > of storing absolute a/c components... > > Well, using a clever loop, one COULD (optionally) make > FlightGear validate its aircraft files automatically and make > it check for aircraft definition files that are using relative > paths instead of available variables for FlightGear's > subfolders, so that these could be 'fixed'. > > Basically, FlightGear would recursively read in all files and > check the resulting absolute path for all relative paths - IF > a resulting path is equal to a supported "short cut" variable, > it could replace the corresponding relative path. If a > relative path doesn't match any pre-defined variables, one > could at least change them in a way, so that they refer to > $FG_ROOT - which would also result in maintaining dependencies > regardless of the actual file's location. > > Something like that might in come handy anyway, when it comes > to 'fixing' the current files ... > > > -------- > Boris
In the short term I think that a simple single repository of a/c archives will do. This would really mean that instead of 'updating' an a/c it would be replaced, but it would be simple to do. All that would be needed would be to agree a location and a procedure for users to follow - the a/c developers would then ensure that their archives worked with those procedures. The reason I mentioned the rdbms stuff was more 'food for thought' than something that might be considered for implementation right now. Consider though, storing the a/c in an rdbms... you want just Boeing two engined etc a/c - just run a query... ... or you just want to compare a/c using the same family of engines - just run a query. LeeE _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
