_checked
- cbor_value_get_raw_integer
- cbor_value_to_json_advance
- cbor_value_to_json
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
-value/
(I've been asked to write "the reference on passing by reference" and
"pointers on passing by pointer", but never got around to it)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
On Wednesday 30 September 2015 13:05:23 Light, John J wrote:
> There are 11 pointers, so on a 64-bit machine, we copy 88 bytes.
On a Sandybridge, that's 2x256-bit moves, one 128-bit move and one 64-bit
move. Or 5x128-bit moves and one 64-bit one.
--
Thiago Macieira - thiago.maci
On Wednesday 30 September 2015 13:19:02 Thiago Macieira wrote:
> On Wednesday 30 September 2015 13:05:23 Light, John J wrote:
> > There are 11 pointers, so on a 64-bit machine, we copy 88 bytes.
>
> On a Sandybridge, that's 2x256-bit moves, one 128-bit move and one 64-bit
le values are defined:
20 false
21 true
22 null
23 undefined
In addition to that, values 25-31 are reserved and cannot be used.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
On sexta-feira, 15 de abril de 2016 11:16:34 PDT Otavio Pontes wrote:
> Do we have any update in this topic? Have the patches been submitted to
> Eclipse tinydtls repository?
They haven't yet. We're analysing the Eclipse Foundation's CLA. That may be a
showstopper.
t. (multicast socket is shared commonly)
>
> However, this random port assignment policy makes the OIC client re-discover
> whenever OIC server restart, which is very cumbersome task.
>
>
>
> I propose the default UDP unicast port for OIC for example ~3337, OIC
>
requires finding the server device
> again when target reboot. As far as I remember Thiago also understood this
> requirement before. Discussion was not for undiscoverable service.
>
>
> ---?? ???---
> ??? : Thiago Macieira/thiago.macieira at intel.com
> : 2016/04/19 00:38
tend to cover every case but just maximize the hit
> ratio. BR Uze Choi
>
>
> ---?? ???---
> ??? : Thiago Macieira/thiago.macieira at intel.com
> : 2016/04/19 11:44 (GMT+09:00)
> ?? : Re: [cftg] RE: OCF IANA Port Number Assignment
>
> Hi Uze
>
> I don't see
about the port
> designation api, it has some issue as I explained in mail for answer to
> Ravi just little before. Originally iotivity had a logic assigning the
> specific port before, we figure out that this port is already registered in
> IANA with different purpose. This is the reason
hed with it.
> However, could you explain for port hint in detail?
> BR, Uze Choi
>
>
> ---?? ???---
> ??? : Thiago Macieira/thiago.macieira at intel.com
> : 2016/04/19 13:43 (GMT+09:00)
> ?? : Re: [cftg] RE: OCF IANA Port Number Assignment
>
> Hi Uze Note that ha
it diesnit work and we had long discussion for this api fix with
> John Light before. For the implementation choice detail please refer to my
> today reply mail to Ravi. BR Uze Choi
>
>
> ---?? ???---
> ??? : Thiago Macieira/thiago.macieira at intel.com
> : 2016/04/19 1
r to reduce re-discovery problem.
>
>
>
>
> ------- Original Message ---
> Sender : Thiago Macieira
> Date : 2016-04-19 15:20 (GMT+09:00)
> Title : Re: [dev] [cftg] RE: OCF IANA Port Number Assignment
>
> That's an IoTivity problem. We chose not to provide this functionality.
>
ant solution to resolve my issue, but only discussion happen without
> answer.
> --- Original Message ---
> Sender : Thiago Macieira
> Date : 2016-04-21 00:26 (GMT+09:00)
> Title : Re: [dev] [cftg] RE: OCF IANA Port Number Assignment
>
> Before we discuss that, do yo
et of IANA port numbers ... BR Markus
>
> --- Original Message ---
> Sender : Thiago Macieira
> Date : Apr 22, 2016 02:53 (GMT+09:00)
> Title : Re: [dev] [cftg] Re: Re: [cftg] RE: OCF IANA Port Number Assignment
>
> Hello
>
> I've already answered, but I will repeat
20 20:04:06 tjmaciei-mobl4 avahi-daemon[36857]: Registering new address
record for fd2d:2122:f24:0:59ce:bc6d:46f3:1a49 on wlp2s0.*.
This is even without rebooting. After any reboot, it changes again.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
fferent functionalities on multiple ports
> (e.g., only discovery on 5683 and data transmission on other ports - that's
> how it works now). I know this has implications on having multiple
> instances running on one device, but the default is to have only one
> instance per device. I think
RE: OCF IANA Port Number Assignment
> I agree with Thiago here.
>
> Dave
>
>
> > -Original Message-
> > From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] On
> > Behalf Of Thiago Macieira
> > Sent: Monday, April 25, 2016 8:51 AM
> > To: cftg
> From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] On
> Behalf
> Of Thiago Macieira Sent: Tuesday, April 26, 2016 12:51 AM
> To: cftg at openconnectivity.org; ashok.channa at samsung.com
> Cc: Wouter van der Beek (wovander); Uze Choi;
> iotivity-dev at lists.i
t you
reuse some of the clean up they've done and that you don't introduce more
clutter on the platform abstraction.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
is only affects std::string (and maybe a handful of other functions in the
Standard Library).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Test installed system-wide?
2) do you have anything in that extlibs build dir?
3) if so on #2, can you confirm the symbol in question is present in
libgtest.so?
nm -DC path/to/libgtest.so | grep GetBoolAssertionFailureMessage
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
matters. Make sure that -lgtest
appears on the command-line after caprotocolmessagetest.o.
Or build GTest as a shared library.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
last e-mail, it is very clear what should be done.
> Is there any reason not to fix this ?
Hello Daeken
You're right, there's no reason not to fix. I just didn't do it because it
sounded so obvious I thought someone else would do it.
Go ahead and replace stdassert.h with ass
that we do not NEED an IANA port registered, is
> > > that
> > > the unsolicited connections never happen. All connections are
> > > preceded
> > > by a discovery request, and responses to said discovery results in
> > > the
> > > port being
ayer now and
> because of that there is no hand-written HTTP Stack used in source code.
> It?s confirmed in one of the mail. Not sure which hand-written HTTTP stack
> you are referring now.
Which library did you decide to use? Does it have HTTP2 support or plans to
have one?
tibility with OIC 1.1
clients?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
rned just like the main
IoTivity implementation, via Gerrit and by tracking bugs in JIRA. We are
proposing:
Maintainer: Kishen Maloor
Sub-maintainers: Otavio Pontes, Flavio Ceolin
Architect: Thiago Macieira
Q: how big is the implementation?
Last time we measured, we w
On ter?a-feira, 2 de agosto de 2016 06:50:22 PDT ?? wrote:
> We are planning to use LibCurl. But there were some gaps using it for our
> requirements. After feasibility analysis , we will update it in wiki page.
Can you describe what the issues with libcurl were?
--
Thiago Ma
no such thing as "dc_tg". You must be talking about an OCF task
group, which is out of scope. OCF does not decide what goes in IoTivity and is
not in the decision-making path. There's no need to pre-brief OCF.
That said, I did pre-brief a lot of people during the June meeting and a
presentation about what we were looking at was circulated.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
On quarta-feira, 3 de agosto de 2016 12:58:00 PDT Gregg Reynolds wrote:
> On Mon, Aug 1, 2016 at 3:42 PM, Thiago Macieira
> > This email serves as the official request and the beginning of a
> > discussion for
> > a new Git repository in iotivity.org to contain a new impl
/press-releases/thread-group-open-connectivity-foundation-create-liaison-agreement-increase-application-connectivity-choice-connected-home
http://threadgroup.org/news-events/press-releases/ID/113/The-Thread-Group-and-Open-Connectivity-Foundation-Create-Liaison-Agreement-to-Increase-Application-Connectivity-and-Choice-in-Connected-Home
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
wo distinct, interoperable, implementations a *requirement*
> for the project.
I'm not ready to go that far, but it's something to remember.
Let's be glad that we're developing one in parallel with the spec. That
doesn't usually happens in industry standard groups.
--
Thiag
er come up in my
professional life.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
is updated, to limit breakage.
I wouldn't mind a +2 to https://gerrit.iotivity.org/gerrit/9867 too.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
just fine and that you
don't get to supply additional parameters (CAs, mutual authentication, etc.).
Those are perfectly fine answers. But we need to see a discussion of those.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
On quarta-feira, 3 de agosto de 2016 15:04:07 PDT Gregg Reynolds wrote:
> On Aug 1, 2016 3:42 PM, "Thiago Macieira"
> wrote:
> ...
>
> > Q: what OSes does it support?
> >
> > Currently, it supports Zephyr (https://zephyrproject.org) primarily.
>
&
'll look
for other hosting possibilities.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
ddress. That implies that it can be
obtained from the kernel. strace identifies these operations:
socket(AF_BLUETOOTH, SOCK_RAW, 1) = 3
ioctl(3, HCIGETDEVLIST, 0x55e18eaca010) = 0
ioctl(3, HCIGETDEVINFO, 0x55e18cc3bac0) = 0
Can't you use that to get the device's own address
iginal Message-
> > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-
> > bounces at lists.iotivity.org] On Behalf Of Thiago Macieira
> > Sent: Wednesday, August 3, 2016 11:36 PM
> > To: iotivity-dev at lists.iotivity.org; jihwan.seo at samsung.com; JinHyeock
>
new
> APIs which makes backward compatibility issues really matters during
> actual product deployment.
Those are valid concerns. But they are also the very concerns that caused us
to create a new source code: to retain the current implementation's
compatibility and API.
As far as I can see, the risk in having the new implementation under IoTivity
is that the community would be left with the task to maintain it if Intel
walked away from this project. Since this is a valid and serious concern, I
will get from my management some kind of pledge of continued development and
support for given period of time. Will this alleviate your concern?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
ence of the EP fields:
the device simply doesn't add its BLE address. If it responds with no address
at all, OIC 1.1 rules apply and the remote side understands as "the address
this response came from". And then, if that side is an RD, it can fill in the
details of the endpoint
nstead, BLE devices need to be "proxied", by a bridge or Resource Host.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
On quinta-feira, 4 de agosto de 2016 09:48:05 PDT Thiago Macieira wrote:
> Those are valid concerns. But they are also the very concerns that caused
> us to create a new source code: to retain the current implementation's
> compatibility and API.
Ashok, do you have further concern
file, which transmits the regular
UDP/CoAP packets that you see in WiFi and 6LoWPAN.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
), will attempt to pass
certification and be interoperable with the main implementation, and finally,
it
is expanding IoTivity's support base to areas where it didn't before.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
shall we *suspend* the IoTivity 1.2 or 1.3 release
indefinitely? The delay is of at least 9 months, probably more.
> This rules out your concern of memory. Leaving onle the above mentioned 2
> points for discussion.
That's three and one of them requires dropping our entire API and
; high-level caller to process via select(), etc. It's not un-doable, but
> definitely would take API reworkings at this point.
That's what we thought when we started Soletta. Turns out that it's not
abstract enough for Zephyr.
--
Thiago Macieira - thiago.macieira (AT) intel.co
ht now, since it's not part of the spec.
Let me repeat: the current implementation does not address the market. To
address the market, we can either make the current implementation do it or add
a new one. Is it ok to indefinitely suspend the IoTivity 1.3 release until
we'r
vity.org/gerrit/#/c/10455/
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
a.org, but only OCF members can make those
submissions official part of the OCF specification.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
use
IoTivity on those devices, we'll be interested in your experience.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
able to find it in
> IoTivity site.
Hello Karthikeyan
We're not working on it, but the IoTivity Constrained Framework does have some
code imported from Contiki. Porting shouldn't be too difficult.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
for working with IoTivity?. We unable to implement the whole layers
> as the end device doesn't have that much memory or space.
>
>
> Right now I am working on implementing the layers specified in C SDK of
> IoTivity.
>
>
> Regards,
>
> karthikeyan.
>
> __
the topic. Maybe you
can coordinate your efforts.
Current codebase:
https://gerrit.iotivity.org/gerrit/gitweb?p=iotivity-constrained.git;a=summary
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
xplain how to port to other OS would be great.
Hello Jack
There's currently no port for RIoT and no one working on it.
We're working on the documentation. What I can tell you so far: to port, go
into the port/ dir and create a subdir with your OS, then write the code
equivalent to linu
her OS.
> It will make people who wants to port to their OS happy and then more
> OSes will be used with this implementation.
Hello Jack
We are working on documentation for this.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
at's ok because those files aren't part of the build and do not end up in any
binary image.
> I create Jira ticket about this issue.
> https://jira.iotivity.org/browse/IOT-1626
Should be closed as a non-issue.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Arc
gt; Thanks,
>
> Mitch
>
>
>
> From: cert_wg at openconnectivity.org [mailto:cert_wg at
> openconnectivity.org] On
> Behalf Of Mark Trayer
> Sent: Tuesday, November 22, 2016 8:26 AM
> To: Mitch Kettrick; '??? (Uze Choi)'; '???'; 'Heldt
Mitch
>
>
>
>
>
> -Original Message-----
> From: architecture_tg at openconnectivity.org
> [mailto:architecture_tg at openconnectivity.org] On Behalf Of Thiago Macieira
> Sent: Monday, December 05, 2016 3:58 PM
> To: Mitch Kettrick
> Cc: Richard Bardini; Dwarkaprasad Dayama; ioti
> From: architecture_tg at openconnectivity.org
> [mailto:architecture_tg at openconnectivity.org] On Behalf Of Thiago Macieira
> Sent: Tuesday, December 06, 2016 9:21 AM
> To: architecture_tg at openconnectivity.org
> Cc: Mitch Kettrick; uzchoi at samsung.com; 'Richard Bard
s they
> > know each other from before. We tend to use options to indicate
> > capabilities, either actual CoAP options or indications in the data
> > structures exchanged.
I'd much rather allow somehow the detection of capabilities rather than an
all-or-nothing versi
ised to a given set of
resource possibilities.
Does this help?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
On ter?a-feira, 13 de dezembro de 2016 16:51:39 PST Prakash Karthikeyan wrote:
> Segmentation fault (core dumped)
The application crashed.
Please provide the backtrace from a debug build.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technol
as CoAP or Secure CoAP (DTLS). Since IoTivity uses a random port number for
unicast packets, Wireshark doesn't know what the protocol is.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
happens if the
RH hasn't registered itself yet: the constrained device will not be able to
publish any state yet and it should repeat the query #3 (Proposal) after an
interval.
If you meant the other way around, I don't understand the proposal.
Also, as another question in the thread
ad of CoAP-over-TCP?
Does this require an OIC cloud? Or can this cloud be deployed by anyone? If
the latter, what is the server software that should be used?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
hat the only flag interesting to us is still T, so your
examples don't change.
slides 7, 9, 10: where you wrote "coap://2001::DB8", it should be
"coap://[2001:DB8::]"
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
n for the IoTivity mini-summit
after that. So please do it before the deadline!
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Can you clarify what you would like to add to
IoTivity?
Are you thinking of machine-learning functionality, data storage, etc.?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
ve not thought of.
Hello Jihun
This is an interesting proposal. At this moment, I don't have anything to add.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
specific titles and intents for each sessions
>
> What is our startegy for upcoming the first IoTivity event on April ?
>
> Daniel,
>
> --- Original Message ---
> Sender : Thiago Macieira
> Date : 2016-02-02 11:53 (GMT+09:00)
> Title : [dev] Open IoT Summi
s finished?
Isn't this specified in the CoAP spec? See
https://tools.ietf.org/html/rfc7252#section-4.8
https://tools.ietf.org/html/rfc7252#section-8.2
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
icky as on more resources are
> added.
I think this is not an acceptable solution.
Additional Con: since the default interface is unknown without first querying
the device, no one will write code that uses the default interface.
Conclusion: default interfaces are useless and we could just as well
ts: it supports.
b) if the client is programmed to use an optional interface if it is present
and fall back to a standard one if the optional isn't present, the storage
is one bit.
Note how default never came into the discussion.
> 8. IMHO it is important to see how OIC can
es for that resource,
> which can save couple of bytes.
Understood, but I don't see how that supports or detracts from the option. As
Ravi said in his reply, all resources must implement all the mandatory
interfaces, regardless of how much data they would produce. Leaving it up to
the devic
duction session in Tizen
> Developer conference 2015 Bangalore.
Hello Manas
The sessions were not recorded. We intended to record them later ourselves
using the OIC's WebEx infrastructure, but have never got around to doing it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
n the same device, we simply need the client's discovery
packets to somehow discover the server that is running there. From that point
forward, everything should proceed normally with current code.
All we need for this is to configure our multicast query packets to be sent
with IP_MULTICAST_LOOP
0)
f.bind(('::', 1234))
f.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP,
b'\xff\x03\0\0\0\0\0\0\0\0\0\0\0\0\0\xfd\0\0\0\0')
f.sendto(b'\n', ("ff03::fd", 1234))
print(f.recvfrom(1))
prints:
(b'\n', ('fe80::210:60ff:fe31:9bb1
that the Bluetooth SIG is working on 6lo-over-BTLE,
which solves the problem by giving us IPv6.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
is equal to having no
default. We may as well abandon the idea of talking about defaults in that
case.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
en
applications failing to communicate when the default in a device is
unexpected.
(hint: add this to the certification testing; the default should *always* be a
nonsensical interface that no one should be using)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
ng in this thread, from what I can see) know enough to
provide relevant information. Since we're speculating, I proposed we table the
discussion on power.
And to repeat: I agree on sending shorter packets. I just disagree on how to
make application developers choose to request that.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
I repeat what I said: making the default vary from device to device is, at
best, a zero gain in having a default at all, and at worse it's a red herring
causing confusion.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Linux,Android and Tizen.
Hello
For Contiki, RIoT and other small OSes, please use Soletta:
https://github.com/solettaproject
It has OIC support inside, along with a lot of other nice things.
We're very interested in your feedback.
--
Thiago Macieira - thiago.macieira (A
Em segunda-feira, 8 de fevereiro de 2016, ?s 16:49:04 PST, Raghavendra Kakarla
escreveu:
> Dear Thiago Macieira,
>
> I have one doubt on this. Could you please clarify me.
> Because it is supported the OIC is it able to communicate with other devices
> which support IoTivity?
Bo
sdk/stack/src/ocp
> ayloadconvert.c#L425 )
>
> Am I missing something?
Hi Salvatore
Why do you need the URL?
Technically, if you have the device name, you have the URL, by composing it
like "oic://".
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
eful.
That's Bluetooth SIG's fault.
Anyway, the point is that this is not an easy topic. There are good reasons to
do it, but it must be done very, very carefully. And I'd like to know of the
benefits (the question above).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
/master/spec/iot-js-spec.md#o
> ic-presence namely, the optional 'USVString url' parameter to 'subscribe()'
> and 'unsubscribe()' would become an explicit 'USVString deviceId'.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
give me the info
> where to add the IPV6 address in the code.
You don't need the address. The interface index is enough.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
GCC on Windows. We'd like to
upstream those changes and begin discussing how to support Visual Studio. I'll
post a separate email with our findings, current state and challenges for
Visual Studio.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
posed maintainer: Gabriel Schulhof
Proposed architect: Sakari Poussa
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
ity-node
and has been developed using the MIT licence.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
that you get a specific commit, tag or
version. You cannot rely on master being compatible with IoTivity.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
e (a lot of things were
"OC" before). And since we may want to rename to OCF now...
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Hello Jinguk
Let me check if that is possible.
On ter?a-feira, 23 de fevereiro de 2016 09:07:06 PST ??? wrote:
> Thiago,
>
> Could you or sakari upload IoTivity JS source codes with Apache v2.0?
>
> BR
>
> Jinguk Jeong
>
> --- Original Message ---
n't try out the experimental code. I
don't think we have a mature enough codebase yet to make long-term promises,
but we should think about it.
But I agree in principle.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
s to know the list of all members so
that it can verify that it received all ACKs.
2) address assignment/generation
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
> How do you think of that?
Hello Jihun
I'm not sure you're talking about a CBOR error or about an ocpayloadparse.c
error. Can you clarify which one it is?
You said you're getting a parsing error. Where? What was the input byte
stream?
--
Thiago Macieira - thiago.macieira (AT
k on log message.
Then I agree it's a bug and should be fixed in ocpayloadparse.c
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
1 - 100 of 909 matches
Mail list logo
