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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 173 bytes Desc: This is a digitally signed message part. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150309/aa9d73c2/attachment.sig>
