search

ublox-rs / ublox

Rust crate to talk UBX protocol to u-blox GPS devices.
MIT License
52 stars 29 forks source link

Proper Versioning Support #43

Open lkolbly opened 1 year ago

lkolbly commented 1 year ago

This project has so far been really bad about handling different versions of the protocol. For examples, see #33 and #24. The goal of this project is to support "all" versions of the protocol, but so far the API pretends that all protocols are the same.

I'm kind of leaning towards defining a module per version. For example, an import might look like:

use ublox::m8::NavRelPosNed;

This has the advantage that there is a clear delineation of protocols, and what packets are supported in which protocol. But at the same time, it means that extra work must happen to take advantage of similarities between protocols. If the user just wants to parse some simple packet that is common across many versions, and they want their binary to be somewhat device-agnostic, then they must separately parse each version:

if talking_to_m8 {
    // Parse a ublox::m8::NavPosLlh
} else if talking_to_f9p {
    // Parse a ublox::f9p::NavPosLlh
}

Additionally, although there is a clear delineation across broad-stroke "m8", "m7", "f9p" labels, there isn't much ability to focus on sub-product version changes. For example, UBX-CFG-TMODE3 on M8 is only supported in protocol versions 20.x, even though "m8" is protocol versions 15 through 23. So the packet would appear to be supported, and the parser would be generated, for all "m8" products. I think that might be fine though.

Anyway. I'm creating this issue so that there's one place to discuss this issue as a whole. My intent is that this is the next minor-bumping release (so, 0.5.0).

gwbres commented 1 year ago

I'm kind of leaning towards defining a module per version. For example, an import might look like:

use ublox::m8::NavRelPosNed;

that approach looks good. We need some kind of wrapper to determine whether this frame is revision dependent or is shared across revisions (so obviously, a little more code complexity and volume). I assume in that scenario it would be interesting to turn revisions into compilation features ?