#16 standalone navdb server
This is referring to the suggestions made in: http://sourceforge.net/tracker/index.php?func=detail&aid=1429639&group_id=9456&atid=359456
I feel this needs to be a separate item, as it really affects pretty much all FlightGear-related projects equally:
- SimGear
- FlightGear
- FGMS
- FGrun
- Atlas
- FGSD
- TaxiDraw
All of these (and probably more!) depend on the FG navdb, running several of these programs simultatenously means currently:
1) statically load the navdb libraries
2) explicitly reload a new image of the file into memory
3) maintain a separate copy of the navdb for each individual program!
This is not only terribly inefficient but also overly complicated concerning the fact that in order to update the navdb format or its code, all programs will have to modified and rebuilt accordingly.
This should not be the case, the most portable and sensible way to address this issue is clearly to consider refactoring navdb functionality out, so that it can be provided in a standalone fashion by a separate program.
This has a number of great advantages:
- navdb programs become "clients" and can easily connect to a running server to send queries
- no need to duplicate the navdb in every program
- helps modularizing overall architecture of Flightgear and its toolchain
- helps parallelizing current code, by running navdb logics within the scope of a separate process
- helps Flightgear tools become easily distributed, as the navdb server could be easily run even on a separate machine from flightgear and its various tools
- allows many instances of navdb user programs to be started without affecting memory use significantly
- all navdb clients connected via network (LAN/WAN) could easily access and share navdb data
- navdb format, structure and code may change without requiring clients to be rebuilt
The most straightforward way to implement this would probably be a tiny SQL database providing network access via a subset of SQL, alternatively one might want to look into LDAP or other ways to provide directory-based network access to the navdb
Logged In: NO
In a multiplayer/network'ed usage scenario, this would not only be the easiest but also the most reliable way to ensure that all instances of FlightGear and its various tools are using the same set of underlying navaid data, so this also provides an important means to synchronize data usage.
Logged In: NO
I noticed this discussion on the fgms page, just dropping in to make some remarks:
- the fg devs are unlikely to accept a conventional database scheme for the navdb: a couple of years ago, such a scheme was in place and it got replaced by the current scheme of using compressed plaintext file, back then the author of the new scheme was considering to provide a full blown DAFIF parser, so that all of the dafif data could be provided and used in fg.
- if you want to make sure that an alternate scheme can be accepted, you also need to ensure that the corresponding multi-platform frontends are available to easily import, modify and update data - at least as easily as is the current scheme of using plaintext files.
Logged In: NO
as rightly mentioned before, this should be discussed in a more prominent place as it would inevitably affect most Flightgear related tools that are working with some form of navigation data, maybe the wiki would be a better place?
Logged In: NO
FYI, navigation information as needed by simulators and real aircraft/avionics is based on the ARINC 424 standard and is regularly updated (28/56 days) in the form of so called "AIRAC cycles". This data contains all information needed: navaids, waypoints, fixes, approaches, airspace boundaries, terminal procedures and much more.
Logged In: NO
basically this is -also- about parallelizing and distributing flightgear, there were discussions on the mailing list to consider using ORBs such as CORBA (norman vine suggested to check out ice for this very purpose: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg09078.html)
Logged In: NO
Parallelizing Flightgear is discussed at least once every month on the fg devel lists (and that's been the case for years now-to no avail so far!), only the very recent migration to OSG has improved things somewhat:
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg10274.html
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg06760.html
However, before individual components are parallelized it would make sense to actually determine how to approach this challenge and what additional dependencies would be acceptable ultimately. Otherwise, we might end up with solutions that would eventually be turned down because of their overhead and dependencies.
also see:http://wiki.github.com/ac001/fg-navdata/