On 25 Jun 2011, at 22:59, Alex Perry wrote: > . Does anybody know offhand how much trouble it would be for our > source code to have all loaders of aircraft files go through a library > that understands what a relative URL is? If we can cut that over, > anybody can develop and host an airplane simply by sticking some > static files on the web somewhere. Which can reference components of > other airplanes.
This is 'doable, but quite a bit of work'. What' I've been idly hacking up is a helper tool/library that would process aircraft catalogs (basically the first part of the -set.xml files, slurped together into one or several files, with the aircraft id, metatadata fields, thumbnail URL, a download URL, and an MD5 sum....), and use that info to download aircraft from 'a backend' - the default backend being .zips on a HTTP server, but with the option to support an SVN repo, Git URL or whatever if the backend can be glued in. (So you'd have a stable version of the 744 pointing at an HTTP server, and a separate entry in the catalog, with a 'development' metadata flag set, pointing at the live Git repo, potentially - and could switch between them) (If the catalog entries encode the min- and max- compatible flightgear versions for a particular aircraft variant, this also gives us a way to keep the '2.0.0 compatible' archives available for legacy users, which I am sure they would appreciated) The tool code then does the work of fetching updated catalog XML files (eg, daily), and checking for updated version of aircraft, supporting multiple concurrent variants of aircraft, and crucially, placing the extracted/downloaded zip/Git repo in a place fgfs can find it. The reason I'm building this as a library/command line tool is, obviously the various GUI launchers might want to use it, but as Vivian pointed out, there are good reasons to be able to download/manage from inside FG - as was just proved with terrasync :) It *is* possible to go to the next step, and keep the .zip files as compressed blobs, like Java .jar files - but that means a lot more FG hacking to get the OSG file loaders and other places we load files, using a different stream backend. Entirely possible, but I'd sooner establish the core concept - aircraft are pulled as blobs from HTTP - before worrying about the niceties. Code wise, I have about 30% of this prototyped - but not at a point where it can be tested. Since it appears to be a hot topic, I am thinking i should revisit it for 2.5 :) James ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
