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.
> 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.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
