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 1:45 PM > To: Junghyun Oh > Cc: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] [oswg] Re: Group Action Set discussion > > On Tuesday 10 March 2015 01:35:28 Junghyun Oh wrote: > > Hi Thiago, > > > > The string(actionSet) is for the in-process-use only. :) Meaning, the > > actions will be tokenized and not all but only some of the tokens will > > be sent over the wire. > > > > For example, in the actionSet "AllBulbOn*yyyy-mm-dd hh:mm:ss > > 1*uri=coap://x.x.x.10:xxxx/a/light|power=on*? the {?key?:?power?, > > ?value?:?on?} will be delivered to ?coap://x.x.x.10:xxxx/a.light > > <coap://x.x.x.10:xxxx/a.light>? at ?yyyy-mm-dd hh:mm:ss? > > Hi Jay > > I'm ok with us describing the action set that way, but we we shouldn't have > that in the API. Instead, let's simply say the API should take the destination > and the command as separate parameters. Tokenising at runtime seems like > a poor choice in performance aspect. > > Also, I highly question having a deadline for sending. Anything we receive > should be sent immediately. If the user wants to send later, they can easily > write their own timers and deadlines.
I think that the local stack that is sending the request is not handling the timer. It is the service that is receiving the request that is handling that. It sounds like this is behaving more and more like an IFTTT engine. Wouldn't is be better to incorporate an existing IFTTT engine than re-invent the wheel. In addition, an IFTTT engine offers a lot of other capabilities. > > The main reason why we didn?t use JSON format for the ActionSet is > > because, as you may already notice, once we register the actionSet > > with JSON format, we have to parse it inside the Base in order to > > check when & where to sent the actions. > > Which is solved by not using a string in the first place. > > > Then the JSON parsing logic will influence the size of the Base which > > we also don?t want it to be. In order not to increase the size of the > > Base critically and minimized the modification work inside the base. > > we?ve defined such format to implement the ?GroupAction? feature. > > > > However, as Hyunjun mentioned in the previous his email, we do agree > > your suggestion and we also had proposed the same idea. > > Therefore, if it?s okey we?d like to discuss about including the > > limited JSON parsing functionality inside the base OR we?re open to > > discuss about the more efficient alternatives if there?s any. :) > > I don't want JSON in the base at all. In fact, in my review of the draft > specification, I pointed out all places where JSON was mandatory and > requested they be changed so that JSON is optional and CBOR (RFC 7049) is > mandatory. > > I am also willing to write the CBOR encoder and decoder for the base -- I > implemented one in four days two days ago, including full unit test suite, so > I > can easily do it again. > > But for this feature, I'd rather not have any parsing of any kind. It should > come in structured format from the user. BTW, can you provide any guidance on code size and execution size of your CBOR implementation? It is my understanding that CBOR (even with string data typing) is smaller machine code, faster execution, smaller RAM footprint, etc. in addition to the smaller encoding and safer execution. NOTE: You can write very robust/safe JSON parsers, it is just a little harder. 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/20150309/664074b2/attachment.p7s>
