On Fri, Jun 1, 2018, 9:08 AM Thiago Macieira <[email protected]> wrote:
> On Thursday, 31 May 2018 22:13:32 PDT Ondrej Tomcik wrote: > > I expected that - "implementation of the coap in the golang" is clear > > enough, as it is standardized protocol > https://tools.ietf.org/html/rfc7252 > > . > > > > Or, if it was not - "go-coap implementation which supports TCP with TLS > and > > is compatible with the IoTivity" could help that as the goal is to have > it > > fully compatible with the IoTivity, it is just implementation of the coap > > protocol based on RFC7252 with emphasis on tests with IoTivity SDK in the > > golang. > > > > Currently, we were not able to find a go-coap library which supports TCP > and > > DTLS. Only UDP. Thats why our own implementation - in the IoTivity > project, > > as we need it for the new cloud based resource directory and account > > server. > > Thanks, that's now clear. > > 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? 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. 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. 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. Summary: the structure of the project needs some rethunking.
