Hi Thiago, Thiago Macieira <thiago.macieira at intel.com> writes:
> As promised, I've written a proposal for CBOR. See more details and rationale > in https://jira.iotivity.org/browse/IOT-449. > > Summary: the proposal is to > * update documentation, variable names and comments that assumed that JSON > would be the only type of payload > > * the OIC protocol be modified so that any information that the IoTivity C > stack may need in order to route packets properly be moved from the CoAP > payload to the CoAP options headers (for example, device unique IDs > the C stack be extended with an API for setting and retrieving the payload > type (CoAP Content-Format) > > * decouple the encoding of the payload from the data transmission > > * remove the dependency on cJSON and remove the sources from the IoTivity > repository > > * add an API to the C SDK to allow one to encode and decode CBOR payloads > > * modify the C++ stack to use the API from the previous bullet > > I will provide the encoder and decoder for CBOR in the form of an extlib that > we can add to IoTivity and replace cJSON with it. Time-permitting, I will also > benchmark it against cJSON. > > Expected FAQ: > [...] > > Q: What would the API look like? > A: Something like this: > > CBORValue value; > if (!cbor_map_get_value(&request, "href", &value) || > !cbor_string_equals(&value, "/a/light")) > return; > > CBORValue rep; > if (!cbor_map_get_value(&request, "rep", &rep) || > !cbor_value_type(&map) == CBOR_TYPE_MAP) > return; > > // extract properties: > bool state; > char *color; > if (cbor_map_get_value(&map, "state", &value) > && cbor_value_get_boolean(&value, &state)) > set_light_state(state); > if (cbor_map_get_value(&map, "color", &value) > && cbor_value_get_string(&value, &color)) { > set_light_color(color); > free(color); > } > Just wondering if something similar to what GATT does would work, using binary identifiers instead of string identifiers, emulating what GATT does with 16-bit, 32-bits and 128-bit UUIDs for characteristic value types. So the example becomes something like this: CBORValue value; if (!cbor_map_get_value(&request, OIC_HREF_UUID, &value) || !cbor_string_equals(&value, "/a/light")) return; CBORValue rep; if (!cbor_map_get_value(&request, OIC_REP_UUID, &rep) || !cbor_value_type(&map) == CBOR_TYPE_MAP) return; // extract properties: bool state; char *color; if (cbor_map_get_value(&map, OIC_LIGHT_STATE_UUID, &value) && cbor_value_get_boolean(&value, &state)) set_light_state(state); if (cbor_map_get_value(&map, OIC_LIGHT_COLOR_UUID, &value) && cbor_value_get_string(&value, &color)) { set_light_color(color); free(color); } Without thinking much about, this seems to open some oportunities to reduce the payload further. Sorry if this was already discussed/considered. > As you can see, all string comparisons except for the extraction of the colour > are zero-copy (in situ). > > Q: Why not EXI? > A: Because we're CBOR is designed to be compatible with JSON, so the > conversion is much easier. EXI is designed to be compatible with XML. > > Q: Why not MsgPack? Why not CapnProto? Why not UBIJSON? Why not ...? > A: Short answer: because Pat told me to use CBOR. > > Long answer: each of those has its advantages but also disadvantages. CBOR > wins against them because: > * it has its own CoAP Content-Format registry number (60), so we don't need > to write "application/cbor" > * it's very space-efficient, trading off some decoding speed for it > * it's extensible, unlike MsgPack > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev Cheers, -- Vinicius
