I've discussed this with Chunky_Ks a lot via IRC, but I think it'd be good to make a more formal post about the ideas that would constitute a new obdgpslogger.
Current ObdGpsLogger Constraints:
Currently, you can get obdgpslogger to read obd codes from a compliant vehicle and log stuff. You can also utilize obdsim's plugin architecture to read values from a non-compliant vechicle and route the values into compliance. This gives obdgpslogger a lot of capabilities, but it still doesn't cover reading or writing mfg-specific codes that logger currently knows nothing about. A rewrite would be necessary to give logger this functionality.
A New OBDd
What would be nice is a 3 part application. First, libobd, which handles communication with the device. Secondly, a pluggable daemon for which a plugin could be written to read and write 3rd party codes through a nice interface. Third would be an interface library for 3rd party apps. This library would provide convenience methods for apps that want to display data coming from the daemon similarly to how libgps works with gpsd. The daemon would communicate with 3rd party apps via a socket based TCP/UDP communication protocol *at least*. Of course, the latter TCP/UDP communication layer could just be another plugin.
In this scenerio, logging would also just be another plugin and obdgpslogger would become the de-facto standard way of communicating with the obd port on *nix platforms (similarly to gpsd).
What do you think?
I like the idea of splitting out obd comms into a separate library, I've been thinking about that for a while. For that matter, it went into the TODO at revision 100; right now, we're on revision 345.
The fundamental different in architecture between gps and obd is that gps can essentially just be listened to; you listen to the stream and pick out the bits you want; if you're sufficiently determined, you can interpolate to get almost arbitrary data rates. OBD is more challenge-request, and highly rate-limited.
My initial inclination is to separate the OBD communication into a separate library, and change logger to use that [should be simple, since the API probably won't change much]. As to a pluggable daemon, I don't know how well it'll actually work. But once I've split the obd comms into a separate library, the described daemon would be relatively easy if you can figure out how to *actually* get everything working.