Derek Pressnall wrote:
If the gpsd falls into catagory 3 (and not 2), then for me that is ok,
as long as it is bug free, will work with updated kernels, and has a
defined api for talking to it from other apps. In that case, I can
treat it as if I'm using a gps chip that spits out the protocal that
the daemon is spitting out. (I assume that is what the daemon is for,
to take the propriarity api on the chip and convert it to a
standards-based api).
gpsd does a bit more and a bit less than that - most chips already spit
out NMEA 0183 sentences. gpsd wraps these and provides a shared
interface to the gps, so that apps don't need to bind to a comm port and
multiple apps can leverage gps data. gpsd will also run in some binary
modes (SiRF and garmin, perhaps others) and will signal to switch
between binary and NMEA modes. Otherwise, diagnostics , gpsfake, etc...
more info (if you are interested) at http://gpsd.berlios.de
The 'bug free' is the part that I would be most worried about - often
the bugs are only discovered after extended use, because real users are
capable of getting machines into states that testers couldn't dream of
:) although not so much with gpsd, which seems to be pretty robust - I
have had problems with older versions where it did not suspend properly
(and was extremely difficult to kill), but I never really sorted whether
that was gpsd or something else.
Now a secondary purpose of having source availability is to study the
code to improve my programming techniques. So having a closed gpsd
doesn't help there. But it doesn't affect the primary purpose. (Of
course, other people have different primary purposes than me, so this
won't apply to them).
The core of gpsd is totally open for code review, I think the closed
binary only applies to the gllin piece, but I could be mistaken.
Rgds,
Joshua
_______________________________________________
OpenMoko community mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/community
