@Thiago,
Between your comments and Dave Thaler's, it seems like there's many reasons we
shouldn't keep a go-coap lib in the repo and very few reasons why we should.
Based on the fact that ondrej created a go-coap repo under his own github
account today, he either agrees with you or has accepted your decision. In the
interest of breaking the law of triviality[1] I hope we can move forward in
this discussion operating on the assumption that everyone agrees with you and
begin discussing our plan of attack for the iotivity cloud. Given your
expertise and authority, I'm very interested to hear your thoughts on my
comments from the wall of text I posted yesterday (5/31/18) regarding the loose
coupling/"backend agnosticism" of the cloud interface.
[1] https://en.wikipedia.org/wiki/Law_of_triviality
@Gregg,
Agreed that "cloud" is an overused and under specified buzz word. That being
said, "cloud native application" does have certain connotations, like being a
microservice architecture that's designed to rapidly scale up/down and with a
certain degree of loose coupling between the microservices to enable easy
refactoring and reuse of the codebase. In the context of the iotivity/OCF
cloud, at least according to section 12.3.6.1 of the OCF core spec, it refers
to what the spec calls a "coap native cloud".
If you want good commercial adoption, you need to compete with the aylas and
xivelys of the world by offering all of the components required to develop an
end to end solution. A scalable and performant coap native cloud implementation
is part of that end to end solution or else there's going to be no way to
control your devices remotely or with a voice assistant. That is, unless you
want to there to be no standardized way for IoT devices to communicate with the
cloud which in and of itself is also going to hurt adoption. A barebones app
that can do discovery/control/wifi easy-setup/cloud setup is probably also
necessary for that "end to end solution", so I'm definitely interested in
checking out that flutter app you mentioned, can you provide a link to it?
Regards,
Scott
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Thiago Macieira
Sent: Friday, June 1, 2018 4:54 PM
To: Gregg Reynolds <[email protected]>
Cc: iotivity-dev <[email protected]>
Subject: Re: [dev] coap-go repository
On Friday, 1 June 2018 13:24:32 PDT Gregg Reynolds wrote:
> > I don't think this should be in IoTivity.
>
> How is this different from the cloud thing? That goes waaaay beyond
> Iotivity. If, strictly speaking, iotivity is about a reference
> implementation of the OCF protocol, then what is a project involving a
> cloud server etc doing in the iotivity project?
There has to be at least some relation to IoTivity and the OCF protocol /
standard. A mere CoAP implementation with no intention to follow by providing
OCF-compatible services on top doesn't cut. A Cloud implementation that is used
to talk to some API provided in IoTivity is.
> Let's be consistent. If the proposal under consideration can be viewed
> as a component that implementors can use to build their own
> OCF-compliant engines, then we can only reject it on pain of inconsistency.
Two wrongs don't make a right. But note I don't think I'm being inconsistent.
I don't think IoTivity should accept projects that just happen to be components
to someone who may want to implement OCF services. Otherwise, we would find
ourselves hosting operating systems, graphical libraries or HTML generators.
Note: I did think and propose expanding the scope of the IoTivity project to
include more IoT-related technologies. That extension was not accepted, so I'm
now following the directions the project is going on.
> Let's back up and look at the big picture. The kernel of iotivity is csdk.
> The cxx stuff is just another language binding - it should not be
> privileged information. The Java API is no different - it depends on
> the cxx API, but that is optional, I have a Java API that depends only
> on the c API.
Ok.
> More language bindings is better. I guess we have javascript bindings,
> but you would never know that from the website. I'm looking at Lua. I
> have a working Flutter implementation. Go would be nice. Swift, c#, etc.
Sure. I don't have a problem with this.
If the proposal were to create a Go API for IoTivity in the long run, I would
support it. It isn't. I asked specifically and the proposal is to do CoAP
*only*.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
-=-=-=-=-=-=-=-=-=-=-=-
Links:
You receive all messages sent to this group.
View/Reply Online (#9632):
https://lists.iotivity.org/g/iotivity-dev/message/9632
View All Messages In Topic (16):
https://lists.iotivity.org/g/iotivity-dev/topic/20405830
Mute This Topic: https://lists.iotivity.org/mt/20405830/21656
New Topic: https://lists.iotivity.org/g/iotivity-dev/post
Change Your Subscription:
https://lists.iotivity.org/g/iotivity-dev/editsub/21656
Group Home: https://lists.iotivity.org/g/iotivity-dev
Contact Group Owner: [email protected]
Terms of Service: https://lists.iotivity.org/static/tos
Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub
Email sent to: [email protected]
-=-=-=-=-=-=-=-=-=-=-=-
