GPSD to Remove D-BUS Support in Favor of GeoClue

[antonm]

Just got a message from the author of GPSD that he wants to remove D-BUS support out in favor of freedesktop's GeoClue service:

freedesktop.org - Software/GeoClue

Not sure if this affecting OpenCPN at all. I did not noted that it uses d-bus.

Could somebody please clarify how currently we are interacting with GPSD in the code? It is also interestig for me since I specilly did nothing for this support in Debian packaging and not sure if something is needed for that or not. On GPSD FAQ I found that they provide libgps library for the interaction, but I currently does not link the package with it and neither I link it with d-bus.

[fulup]

I've done some test with DBUS in the idea of integrating it with OpenCPN GPS+AIS discovery.

My conclusion: on Linux Dbus is the only valid option to handle correctly sleep/wakeup on ram [which is my end goal].

While Dbus API documentation is really bad, its fonctionnalities are just find. For linux Dbus is the only correct way to handle removable devices.

Nevertheless see 3 small remaining points to solve:

• it adds one dependency on dbus client library.
• it imposes some change in opencpn's logic for reading serial link, and on the way to present devices on GUI
• it wont work for Windows, and imposes some form of emulation, in order Windows code to be compatible.

My goal is to propose to OpenCPN author, hopefully within the new couples of weeks, a strawman for a hotplug compatible version of OpenCPN.

[antonm]

Originally Posted by fulup

My conclusion: on Linux Dbus is the only valid option to handle correctly sleep/wakeup on ram [which is my end goal].

That's valid and AFAIK was the reason for d-bus development.

Originally Posted by fulup

• it adds one dependency on dbus client library.

I would suggest to make it configurable. E.g. having configure option --with-dbus that when enabled activates specific d-bus related features. If not than either those features are disbaled or have some other implementation. I may help with autotools build stuff to implement that.

Originally Posted by fulup

My goal is to propose to OpenCPN author, hopefully within the new couples of weeks, a strawman for a hotplug compatible version of OpenCPN.

Please also have a look on geoclue freedesktop.org - Software/GeoClue It works through D-BUS and will be unified GPS API on Desktop Linuxes. Other options like network GPSD or port devices needs to be preserved though.

[fulup]

Originally Posted by antonm

Please also have a look on geoclue freedesktop.org - Software/GeoClue It works through D-BUS and will be unified GPS API on Desktop Linuxes. Other options like network GPSD or port devices needs to be preserved though.

Last year, in a previous attempt to handle sleep/wakeup cycle, I integrated GPSd client lib with OpenCPN. Finally the value added did not justify the cost of the dependency. The main advantage to leverage some client API like GeoClue would to remove NMEA parsing from OpenCPN code. Nevertheless this would significantly impact current code without adding any new feature, which limit the interest for such a work.

[antonm]

Originally Posted by fulup

Last year, in a previous attempt to handle sleep/wakeup cycle, I integrated GPSd client lib with OpenCPN. Finally the value added did not justify the cost of the dependency.

Per GPSD author, the client lib is the prefered way to deal with GPSD. Even if one does not want to link (imo there is no problem with lib dependencies in most Linux distros, but for Windows it gets painfull) it still possible to have "configure" switch and ifdef's in the code.

Originally Posted by fulup

The main advantage to leverage some client API like GeoClue would to remove NMEA parsing from OpenCPN code. Nevertheless this would significantly impact current code without adding any new feature, which limit the interest for such a work.

It will not remove nmea since than we will loose primary way of dealing with GPS through device file. Probably it is not convenient. I personally do not think that GeoClue integration is of any priority. I personaly can configure GPS manually and fine with this way.

The main reason for the post is that I got a message from GPSD author that he plans to remove direct D-BUS support out, since we are not using it anyway we are safe.