I have many comments but no good way to write them, hate typing long things on phone. Another time.
We *should* in my opinion avoid CNC term (OCF is using this so not an iotivity decision exactly)... there is the pretty large CNC Foundation at LF, acronym doesn't mean exactly the same thing. On June 1, 2018 2:20:23 PM PDT, Scott King <scott.k...@fkabrands.com> wrote: >@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: iotivity-dev@lists.iotivity.org >[mailto:iotivity-dev@lists.iotivity.org] On Behalf Of Thiago Macieira >Sent: Friday, June 1, 2018 4:54 PM >To: Gregg Reynolds <d...@mobileink.com> >Cc: iotivity-dev <iotivity-dev@lists.iotivity.org> >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 > > > > > > > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
