Hi Thiago,
I understand your point - I missed the email where you replied to Mitch and
thanks for repeating it here.
1. I think in the current spec there is nothing that prevents a Client from
choosing its own Interface and this can be done with the 'if' query parameter
as you have pointed out
Dear Salvatore,
How can I reproduce your issue?
Thanks,
Tim Kourt
Intel Open Source Technology Center
-Original Message-
From: salvatore.iovene at gmail.com [mailto:salvatore.iov...@gmail.com] On
Behalf Of Salvatore Iovene
Sent: Friday, February 5, 2016 3:59 AM
To: Kourt, Tim A
Cc:
"but smaller packets is always good"
I think I get your point, Ravi, but I didn't want to leave this on the table.
There are many perspectives from which to judge packet size. From a power
point of view, having the packet size match the payload, however long it is, is
most power efficient.
Hi Tim,
my app is already doing that, and after further inspection and placing
lots of log prints in various JNI layer files, I came to the
conclusion that this is not about accessing an object that lost scope.
The crash happens with 100% reproducibility and after a random time
since the request t
Hi:
We have a resource which always response to the client slowly because it
need a few seconds to deal with the request.
Thus we are interesting in the resource property "OC_SLOW".
But we did not find any specific implementation or use case to this property
in IoTivity.
The sample programs, ocserv
On quinta-feira, 4 de fevereiro de 2016 16:50:11 PST Subramaniam, Ravi wrote:
> So giving the client having the option of sending a request without a query
> portion eases things significantly. When a server indicates the default
> interface all it is telling the Client - "if you send me a request
Hi,
Jin: Thanks ? yes, agree, sleep is the key ? this is generally corroborated
from talking to experts in radios. My understanding is that this also differs
between radios.
I think Mitch may have a point too ? the extra bits can affect the ability of
radio to sleep because the extra bits can ca
Hi Markus et al,
I am not sure email is the best to resolve this since it is hard to understand
and sync with what folks are thinking and not just what they are saying. Or
maybe it?s just that I am very email challenged.
There are so many issues to consider to get a holistic view of this. When
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160205/cf0cb203/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: 201602051318948_N3WZA6X7.gif
Type: image/gif
Size: 26778 bytes
Des
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160205/6fd19901/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: 201602051153407_XYH693BI.gif
Type: image/gif
Size: 33647 bytes
Des
Mitch,
Ah ... I didn't see this before I responded to Thiago - I think my response
complements your comments.
Ravi Subramaniam
Principal Engineer
Intel - (408) 765-3566
> On Feb 4, 2016, at 1:50 PM, Mitch Kettrick
> wrote:
>
> Hi Thiago,
>
> Thank you for your reply.
>
> Regarding bandwidt
Thiago,
The reason is primarily MTU which given some of the radios we need to target
can be pretty small. When considering battery is is not a consideration on a
per request or response but when one begins to add extra bytes over time then
it does make a difference (remember many IOT devices ar
12 matches
Mail list logo
