Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Features

> 1. Define your GATT services in YAML.

Uh, nope, thank you.



I'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?


JSON5


YAML5: https://github.com/quasilyte/yaml5

YAML-LD w/ convenience.jsonld or dollar-convenience.jsonld: https://json-ld.github.io/yaml-ld/spec/


I 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.


I 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: