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)
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. :)
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?
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.
Thank you.
Jay.
> 2015. 3. 10., ?? 2:44, Thiago Macieira <thiago.macieira at intel.com> ??:
>
> 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
>
