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. > 3. The CBOR en/decoding might influence the performance. Yes. But JSON encoding/decoding currently influences the performance and decoding JSON is more complex. > 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. > #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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
