Drop HTTP_URL_KEY? about httpebble-watch

[natevw]

Here's some general notes about Pebble/dict/httpebble overhead and optimization. Looks like if a single key is used, there's room for 59 bytes data: http://forums.getpebble.com/discussion/comment/55097/#Comment_55097

That's not bad, but I'd love to squeeze more out as I'm transmitting images and this only allows 3 (of 168!) rows to be transmitted per request. Aleksandyr has some great observations in that post. What if httpebble took in a dictionary+caveats, but then serialized it to {uint16_t key, unsigned type:2, unsigned size:6, uint8_t data[]}? That'd be 3 bytes overhead per Tuple instead of 7, with the main limitation being a somewhat unfortunate 64-byte data limit (and a narrower keyspace, but seemingly more than sufficient).

[natevw]

Actually, you could get 128 bytes data which is then greater than the total input buffer! Basically, use only 1 bit for (primary) type. If set, it's a byte array with next 7 bits length. If unset, the remaining bits are an enum between cstring/int16/int32/int8/uint16/uint32/uint8 — for cstring you can either do Pascal-style length first or scan for the \0.

A little more work to enumerate, but since this would be converted to a Dictionary on the one end and JSON on the other anyway, probably not a big deal. Additionally you could drop the "master" tuple count to save a further byte. This would allow an even 80 bytes of binary response data (under a single key) or 84 if HTTP_URL_KEY is dropped; the only restriction would be all user keys need to be less than 0xFF00.