Hello! For the past year or so I’ve been taking a deep dive into the software, protocols, and tools available for geopositioning. My primary motivation has been to make a nice navigation system for my bicycle with free software and write instructions for others, including empirical information about what the state of the art is and where it’s going. I also want to improve user experience along the way as there are many things that need polishing.
GeoClue is a sort of high-level multiplexer for location information that’s able to dispatch queries to the best practical source so I’m very concerned with it. However it doesn’t seem like there’s a way for folks to add new location information sources without patching and rebuilding GeoClue—do I understand that right? The original proposal for GeoClue that articulated the requirements it would need to fulfill expresses this very well and expressed that it ought to be modular, but this does not seem to be current practice.
For an example of a project that does a pretty good job with having many backends that can be used in any combination (even simultaneously), one might like to take a gander at GNU Libextractor, a library with an accompanying command-line tool for prying metadata out of any and all file kinds whatsoever. A person who is only trying to organize digital photos, for example, might wish to use only those plugins that are meaningful for photos. This is a big deal because every Libextractor plugin hands off files to a library that’d know the format—giving all PDF documents to Poppler to read the metadata, for example—and so letting packagers and users be selective about the backends used is important to mitigate bloat from many third-party dependencies. Libextractor’s approach is old-school: Libextractor can enumerate and load plugins that are shared objects at runtime via dlopen() and dlsym(). If this were the approach GeoClue wanted to try, surely GLib’s GModule helpers would be the way to go.
For example, the Linux kernel has included a GNSS subsystem for quite a while that enumerates receivers. It is very promising to help set up the character special devices correctly and dynamically manage the power of the receivers. There’s also no dedicated USB device class so detecting connected receivers has always been very painful especially in userspace that doesn’t have extra information to go off of. GeoClue already supports parsing the NMEA-0183 format some of these devices output, so a shim to get them to be friendly would be nice. I’m writing this post today to ask whether GeoClue should and/or will change to make future extensions, such as by plugins, practical to craft.
For me personally, I don’t have that particular need, but that would help the plug-and-play experience for others and make it easier for libre mobile device manufacturers to make gizmos that work “out of the box” if the hardware information can be encoded in Devicetree format. To send differential real-time GNSS corrections to my receiver encoded as RTCM SC-104, I’ll need more sophisticated tooling anyway, and gpsd fits the bill for that. However, if the GNSS receiver doesn’t have a fix yet, then it can use assistance data to help speed things up. Namely, a GNSS receiver such as mine can start up much faster if you give it at least a crude guess of where you are, such as could be done with GeoClue’s 802.11 wireless geopositioning. Thus this is a real-world example where a crude position estimate from one GeoClue source can help bootstrap another. If I were to replace GeoClue with a custom “shim” that has the same interface, it would be very challenging to keep that benefit.
Basically, many graphical applications use GeoClue but it requires a lot of hackery to get it to work well. This is why I try to make other users aware of one-line shims that save the day, but ones that would really be more effective being built into the software. If GeoClue were to be given some extra care in these areas, what would that look like? What would be amenable to the maintainers as a long-term solution?
Thanks