3 ms·
> Features > 1. Define your GATT services in YAML. Uh, nope, thank you.
by orphea 3y ago
> Features
> 1. Define your GATT services in YAML.
Uh, nope, thank you.
- foooorsyth 3y agoI mean, defining the service in some sort of universal definition format is clearly the way to go. Working with BLE across platforms is incredibly terse and error-prone. The UUIDs should only be in one file -- human eyes aren't going to notice a single-character mistake in those things. A far-less-error prone and faster approach I've taken recently is just having two busses -- one read/write characteristic for inbound messages to the peripheral, and one r/w/notifying characteristic for inbound messages to the central. Then all messages just get defined as protocol buffers. Adding new characteristics for new functionality is a massive pain. Easier to just add new protos and use the same pipe.
- ForkMeOnTinder 3y agoI'll bite. What other format would you have chosen that's widely supported, easy to read and type by hand, and supports deeply nested data structures?
- andyfleming 3y agoJSON5
- westurner 3y agoYAML5: https://github.com/quasilyte/yaml5 https://github.com/quasilyte/yaml5 YAML-LD w/ convenience.jsonld or dollar-convenience.jsonld: https://json-ld.github.io/yaml-ld/spec/ https://json-ld.github.io/yaml-ld/spec/
- shardulaeer 3y agoI started with TOML but switched to YAML because people are familiar with OpenAPI. Ultimately everything is parsed to a Javascript object so you can have adapters in your favourite spec language.