Hi Thiago, Today you commit the C-BOR contribution plan in OSWG meeting. Then can you share the timeline of it? And, could you explain or share the design document for this implementation? As far as I guess, your idea looks like place the json parser and cbor parser into the C++ OCRepresentation Class to interoperable between constraint device with CBOR parse and rich device with CBOR and JSON parser together. Then CBOR encoder need to be in the base layer(csdk) as like json encoder.
BR, Uze Choi -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Tuesday, March 10, 2015 10:13 AM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] [oswg] Re: Group Action Set discussion On Tuesday 10 March 2015 04:24:13 Junghyun Oh wrote: > Hi Thiago, > > About your opinion on the API ?Should take the destination and the > command as separated parameters?, I think your suggestion is reasonable. > We maybe could add that as a feature improvement candidate for the > next release. However, we have to consider the size increase of the Base code. > (I remember that lots of people were against the binary size increase > that > time) Hello Jay It's exactly because of binary size and code complexity that I make the recommendation to split the parameters. That avoids having to have a tokeniser and parser in the target function, as everything is already separated out. > And, about the ?Setting a deadline for msg sending?, however, I do > not see any difference between having timer & its application > logic(ex. deadline > checking) in the IoTivity Base and IoTivity Application. The only > difference I see is whether applications may use the deadline setting > feature for msg delivery by default or not. (For that reason it?s > better to have this features by default ?cause this feature could ease > the developer?s work) Moreover, there?s no such constraint that all > the messages delivered to the base should be sent right-away. Since > the deadline setting feature extracted from the usecase, I think it?s > valid feature to have. :) The question is how often this is going to be needed. Also, mind you that the application may exit before the deadline happens. What should it do then, should it save the information for the next start? And where? That's a problem more or less easy to solve for an application, but the decisions are much more complex for a library. I'm not questioning the usefulness of the feature. I'm just saying that I don't think it should be in the library, especially not now. I suggest we implement this in an application and later we can see how often it is needed by our users. > I do agree to your suggestion on ?JSON to optional & CBOR to Mandatory > instead?, ?casue I also had considered CBOR as a good alternative of > JSON at the beginning of the project. However, I?m facing a > fundamental question to tackle regarding our effort for such change, > and that is... What is the Requirements or Criteria which lead or > force us to minimize or squad the code during the code contribution in > order to make the IoTivity stack light-weight? I didn't understand the question. Are you asking what our target footprint should be? Or are you asking a more subjective question on where we should focus our efforts given the benefits? > Since we don?t have an answer to that question, I do worry whether or > not we are just abandoning the good options (which may bring us the > lots of > benefits) without valid reasons. I'm waiting for a bit more feedback on whether people think the CBOR idea is a good one (so far, people think it is), especially from the OIC standards people. If I don't get a lot of resistance, I'll implement a simple parser and encoder, then do some benchmarks. I can tell you without a doubt CBOR takes less space on the wire, which is an advantage when it comes to low-power WPAN we're going to see in the IoT world, where maximum packet sizes will be 100 bytes or less. I can also tell you that a compliant and error-checking CBOR decoder is much less complex than a JSON one for the simple reason that it's a binary format, though we won't know the actual sizes until we try. That should result in a smaller footprint and faster execution, but I can't give you numbers until I try. I expect it will take me 2 days to write the encoder and decoder, plus another 3 to write the benchmarks. If someone wants to help, I'd like to know what use is expected in IoTivity: what do you do with incoming calls? When you're about to send an outgoing, what do you do? Examples of packets and usages would be very welcome. -- 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
