Markus, If by 'base', you mean the network stack (Discovery and Connectivity) code, I respectfully disagree. That is like asking, mDNS, SDDP and/or TCP stack to offer scheduled transmission.
If by 'base', you mean the larger SDK, I *may* agree. These behaviors need to reside in resource implementations that can be part of the SDK. The discovery and connectivity logic need to be focus on discovery and connectivity and stay separate from the service that are built above it. Pat From: Markus Jung [mailto:[email protected]] Sent: Monday, March 09, 2015 9:53 PM To: Macieira, Thiago; Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org Subject: Re: Re: [dev] [oswg] Re: Group Action Set discussion Hello, if something like group actions are part of IoTivity then having the feature to schedule the execution seems to be a quite common requirement, so it can provide a good value for application developers. But it requires an active component taking care for the execution, so the question whether it should be part of the base library is valid. Best regards, Markus ------- Original Message ------- Sender : Thiago Macieira<thiago.macieira at intel.com <mailto:thiago.macieira at intel.com> > Date : Mar 10, 2015 04:39 (GMT+09:00) Title : Re: [dev] [oswg] Re: Group Action Set discussion On Monday 09 March 2015 10:59:04 Lankswert, Patrick wrote: > Thiago, > > 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. I don't think such functionality belongs in the iotivity libraries. At least it should not in the base libraries. If I understand this correctly, we're talking about a feature by which a client application sends a request to the server so that it will resend to a given target at a given point in time (group or not). The IoTivity libraries should be able to receive and parse the request, but it's up to the server application to decide how to handle that request. Possible actions would be: 1) store it in an in-app timer list 2) add to a system-wide execution queue, like at(1) or cron(8) 3) reject I think we will need to implement an IoTivity server application ourselves to prove that we can do bridging across network technologies, control groups, do deadline execution, etc. And we may even decide to make some or all of those functionalities part of a library, but it should not be part of the base library. > 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. My implementation is so far tied to Qt and I've been compiling with high optimisation options like -O3 -march=core-avx2. I can't give you the numbers you want for the API we'd have until it's written. The CBOR encoder is 41% smaller (according to size(1)) and runs 23% faster, while the current code for the CBOR parser is is 70% larger than the JSON one and takes 63% more CPU time. I should point out that the Qt JSON support is the fastest JSON implementation I've ever benchmarked, at nearly 3x faster than the next best implementation (libjson-c) and that I have not done much in terms of optimisation of the CBOR parser. For our API, if we decide to do it, I will implement a stream parser, not a random-access one. That is to say, if you're reading a dictionary, you have to handle all entries in the order they come, instead of asking for "rt" and then "cmd". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center <http://ext.samsung.net/mailcheck/SeenTimeChecker?do=66776f433ea48075a2e729e 10af4ac75b868f18c178338e3d543c6261db6206746f49c7f7f4ce1db1fdf754ed276bbedd8c 023f270a836a153cb8b1934afabac2f6aaf3d92ded142cf878f9a26ce15a0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150310/56ba89a2/attachment.html> -------------- 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/56ba89a2/attachment.p7s>
