Interesting idea but I would offer an alternative to JSON for device<-->dweet communication. JSON parsing on small embedded processors is often memory- and CPU-prohibitive. A small (preferably binary) protocol is lighter and faster to work with on these little microproccessors. When I built my Lightcube[1], I designed a binary protocol[2] that is easily parsed on the Arduino or even the smaller ATtiny microprocessors. Designing and implementing the protocol was a learning process for me but I ended up with something that didn't tax the CPU, leaving me more processing cycles to interact with my hardware.
With JSON, it's a trade-off. You're either doing the heavy lifting on device side or you're doing it on the client side.
This was my first project where I worked with binary and I learned some neat tricks. For example, the simulator that runs on the Arduino has to downsample the colors to work within the constraints of the 3-bit color that the "Ansiterm" library offers. When I first approached the problem, I was envisioning a complicated series of "if" statements to map the 8-bit color to 3-bit. Then it hit me: I could simply mask all but the highest bit of each of the 8-bit R/G/B colors and use that to generate my ANSI color blocks. This is something that I might not have learned if I was using JSON to pass the data.
Comments
Interesting idea but I would offer an alternative to JSON for device<-->dweet communication. JSON parsing on small embedded processors is often memory- and CPU-prohibitive. A small (preferably binary) protocol is lighter and faster to work with on these little microproccessors. When I built my Lightcube[1], I designed a binary protocol[2] that is easily parsed on the Arduino or even the smaller ATtiny microprocessors. Designing and implementing the protocol was a learning process for me but I ended up with something that didn't tax the CPU, leaving me more processing cycles to interact with my hardware.
[1] Lightcube: https://github.com/chrissnell/Lightcube
[2] Lightcube protocol: https://github.com/chrissnell/Lightcube#lightcube-protocol
I'm curious about why MQTT didn't work for you.
I've never heard of that until now. Neat. Maybe for my next device.
MQTT indeed is nice!
http://www.infoq.com/articles/practical-mqtt-with-paho
So, it's ugly, but just treat single-level JSON as a really oddly-padded binary blob, right?
Match on opening bracket, skip forward to third double-quote, ingest string until hit unescaped double-quote, process string.
EDIT: You're looking at up to like 6 bytes of overhead:
{"a":"<blob>"}
With JSON, it's a trade-off. You're either doing the heavy lifting on device side or you're doing it on the client side.
This was my first project where I worked with binary and I learned some neat tricks. For example, the simulator that runs on the Arduino has to downsample the colors to work within the constraints of the 3-bit color that the "Ansiterm" library offers. When I first approached the problem, I was envisioning a complicated series of "if" statements to map the 8-bit color to 3-bit. Then it hit me: I could simply mask all but the highest bit of each of the 8-bit R/G/B colors and use that to generate my ANSI color blocks. This is something that I might not have learned if I was using JSON to pass the data.
NEVERMIND THAT, APIS IN THE CLOUD MY FELLOW ENTREPRENEURES