> -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > bounces at lists.iotivity.org] On Behalf Of Thiago Macieira > Sent: Monday, April 13, 2015 12:31 AM > To: Junghyun Oh > Cc: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] CBOR proposal > > On Sunday 12 April 2015 15:57:56 Junghyun Oh wrote: > > Hi Thiago, > > > > In summary, by adapting the ?CBOR? .. (please correct me if i?m wrong) > > > > 1. Stack size will be bit more minimized by removing the ?cjson? > > lib. out of the Stack. > > Hi Jay > > Yes, that is correct. > > > 2. The MAXIMUM size of the payload might be lengthen. > > Not on CBOR's account.
I have found no case where the CBOR encoding is larger than the JSON encoding. > > 3. The CBOR en/decoding might influence the performance. > > Yes. > > But JSON encoding/decoding currently influences the performance and > decoding JSON is more complex. In most of the analysis that I have read, CBOR is faster to encode and decode. We will not know with absolute certainty until we have adopted (externally or internally developed) an implementation. > > 4. Only application using C API would need little updates ?cause of > > this change. > > Correct, except for applications that make assumptions about the payload > being JSON in one form or another. > > > In application point of view(including Service Module), .. > > #1. the total size of the SW that will be ported into the device will > > not change, ?cause the only change is the location of the json > > parser.(stack -> app.), however, having a controllability what parser > > to use would be a benefit. > > The size of the CBOR encoder and decoder will be less than that of the JSON > equivalent. > > > #2. would help App/Srv. developers a lot to enhance or create more > > features which is huge benefit. > > I'm not sure how this one is a conclusion. > > > #3. Since the the performance of the SW is one of the critical > > consideration point to IT or Electronics companies (including Samsung) > > for their product, I?m hoping that this change would not decrease the > > performance significantly. :) And, the benchmark test would help them a > lot. > > Right. Most analysis that I have read indicate that the implementations of CBOR are faster. The ONLY exception that I have seen is in fixed format JSON encoding based on printf. > > #4. I think this is a trivial thing. (Do you think that the API should > > be back-ward compatible?) > > I hope it will be trivial, but you know... "famous last words" and all. > > The API for the OCRepresentation of an attribute map should remain the > same. > > > I think adapting this ?CBOR" would bring us good benefits. > > By the way, could you share us any doc. which could give us the idea > > about where the ?CBOR? will be located in the Stack? > > It will be where cJSON currently is: next to the low-level socket handling > code > (including CoAP) and just below the resource management layer. Said another way, above the C API and below the C++ API. Unless we find (or create) an incredible small (SRAM, flash, CPU), we should eventually aspire to more than one implementation for embedded folks to choose from so that they can trade CPU for flash size for SRAM. For the near term, we just need one really balanced, secure, stable encoder/decoder. Pat -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150413/69f9353a/attachment.p7s>
