Joshua Judson Rosen <[email protected]> writes: > Just from the perspective of maintainability, > I'd really prefer to avoid supporting 3 different APIs
Indeed. Whatever the protocol is, it probably is not a good idea to try to support multiple protocols if at all possible. Compatibility should be provided by the APIs themselves and not each application separately... > Ultimately, I think what's going to happen here is that > gpsd is going to continue fleshing-out its feature-set, > so that it supports things like power-management > (there are people working toward this, right now), and > also supports every piece of GPS hardware under the sun > (actually, it looks like this is already the case...). That's certainly my wish too but I am not sure if I am an optimist here ;-) I wrote down a list of things that I'd like to see in gpsd: A way to turn the GPS on and off ================================ We probably do not want to hard code power management policy. At least the following configurations make sense: 1) start GPS when gpsd is started and stop it when gpsd is stopped 2) start GPS when first client connects to gpsd and stop it when last client disconnects 3) start GPS only when explicitely requested by the user and stop it only when requested by the user. 4) Combine 2 & 3: When the first client connects, ask the user if he wants to start the GPS or not. Similarly, when the last client disconnects, ask the user if he wants to stop the GPS or not. We probably do not want to hardcode the actual mechanism for turning GPS on and off either. At least the following are all alternative ways to do control GPS power on openmoko freerunner: 1) Poke /sys directly and hope you have the right kernel version 2) Talk to fso-frameworkd over dbus and ask it to turn the GPS on or off. 3) Use omhacks library or the omhacks command line tools (e.g. "om gps power 1"). Possible improvement: Support putting the chip to low power mode instead of completely turning it off. Save almanac and ephemeris ========================== When GPS is turned off gpsd should save the current almanac and ephemeris to disk. When GPS is turned on again it should send these back to the chip if they are not too old. Possible improvement: support reading the almanac and ephemeris from some internet service. > In the mean time, though, there's probably going to be some pain; > the reason that I suggest fixing fso-gpsd is that, while it's As I mentioned on IRC, the attached small patch adds a "-r" (=raw) option to fso-gpsd that makes it possible to have the data flow like: fso-ogpsd -> fso-gpsd -> gpsd -> foxtrotgps While this may sound over complicated it is actually not: 1) it allows applications to use real gpsd 2) we can integrate the "fso-ogpsd -> fso-gpsd" part to gpsd gradually without worrying application developers. > One question I have, regarding GeoClue, is whether > we'd be able to switch over to *just* using GeoClue without > losing support for connecting to remote gpsd instances-- $ strings /usr/lib/geoclue/geoclue-gpsd | grep -i org.f org.freedesktop.Geoclue.GPSHost org.freedesktop.Geoclue.GPSPort /org/freedesktop/Geoclue/Providers/Gpsd org.freedesktop.Geoclue.Providers.Gpsd so I kind of assume it supports remote gpsd servers. _______________________________________________ This message is sent to you from [email protected] mailing list. Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
