Thiago, > -----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, March 09, 2015 9:13 PM > 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.
I can get you samples from the code samples, but they are contrived. The most common query would be discovery responses. I think that there are samples in one of the specifications or I can generate one. However, what would be more interesting would be one of the representations from the use case groups like the Smart Home Task Group if you can get a sample. 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/20150310/5a6e9589/attachment.p7s>
