-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API V2 #133
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is all just really great! I had lots of notes reading through this but overall it's an obviously-better direction, better organized, more bang-for-buck, easier and more performant to implement in code.
@@ -10,36 +10,20 @@ import "nanopb/nanopb.proto"; | |||
* CreateDescriptionRequest identifies a device with Adafruit.io WipperSnapper. | |||
*/ | |||
message CreateDescriptionRequest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to get to something better than "description" before we're done. Not sure what right now, depends whether we drop the response part. If it's just checking in with your Semver, maybe "checkin" or something.
*/ | ||
message CreateDescriptionResponse { | ||
message CreateDescription { | ||
Response response = 1; /** Specifies if the hardware definition exists on the server. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noticing the "response" part, I guess even if we wanted to do away with this response entirely, we'd need a way to signal that the checkin failed in this way (board lookup failed). Maybe that's another Error message type and the broker can just send that.
proto/wippersnapper/i2c/v1/i2c.proto
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I2C is still so massive and complex! I have a lingering feeling that there's more useful refactoring to do here if we focus on it, perhaps during implementation or an early investigative spike.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Keeping this conversation open as a reminder
//digitalio.proto | ||
wippersnapper.digitalio.v1.DigitalIOEvent digitalio_event = 1; | ||
// analogio.proto | ||
wippersnapper.analogio.v1.AnalogIOEvent analogio_event = 2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we avoiding an *Added
event for io components? I forget if we talked about that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure, what are your thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know the hardware side of course, but if you can definitely tell if you've successfully connected the selected component, then yeah I'd advocate we have AnalogIOAdded
and DigitalIOAdded
messages to fit the pattern and improve user experience.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lorennorman To clarify here - we want a new message called AnalogIOAdded. We are not changing AnalogIOAdd
to AnalogIOAdded`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, looks reasonable. I'd consider removing the deprecated fields completely at this point, as you are making such large API changes that no existing code will be compatible anyway.
…strip nanopb dep off the rest
… I2cDeviceDescriptor
WipperSnapper API V2 aims to address:
signal
sensor.proto
pin.proto
intoanalogio.proto
andanalogio.proto