From: [email protected] <[email protected]> On Behalf Of Scott King Sent: Thursday, May 31, 2018 3:33 PM To: [email protected]; Thiago Macieira <[email protected]> Subject: Re: [dev] coap-go repository
Thiago, The iotivity project already maintains its own fork of libcoap, what is different about doing the same for a golang implementation of coap? We're trying to delete the iotivity fork of libcoap, and it was a bad idea to begin with. That's because there's already active maintenance on the original libcoap (more than on our obsolete fork). The original libcoap is not iotivity specific, and has had additional RFCs implemented and bug fixes beyond the obsolete version in iotivity. We don't want to repeat the same mistake. The iotivity community is likely the largest/most active open source community that has a use case for, and expertise in, coap, so it would be logical to host that codebase somewhere that will have high visibility to this community (though there may be a better way of achieving this goal than having it in the iotivity repo). Yes. Having a separate repo that is usable by both iotivity and other projects gives both a wider (more active) set of potential maintainers, and a wider set of actual users of the codebase. Dave Also, the intent is to use this lib in the ocf cloud code so while the lib itself may not be OCF specific, it will be developed and maintained for OCF use cases. I've had ongoing communication with ondrej about the cloud subproject (sorry Gregg for using "the other other c word") and we seem to be generally on the same page so hopefully I'm not misrepresenting his intentions. At a high level, we're interested in refactoring the code to be more performant (using golang), scalable (by adding kubernetes integrations), and fix some architectural concerns (ex: how can you make the interface containers stateless/12FA friendly if they're responsible to handling long lived TCP connections?). I'm personally interested in making it more adoptable by enterprises and public clouds by making the code less tightly coupled to a specific DB/message queue/authN provider. It's going to be a lot easier to convince public clouds like gcp/azure/bluemix to support OCF if it's just another protocol that they can support in their managed iot messaging services and can utilize their existing auth/DB/pub-sub services. Part of my motivation for that loose coupling is that I don't think we'll see mass addition of OCF without a managed OCF cloud (pardon the terrible phrasing) offered from one of the "big 4" public clouds. There's just too many hardware companies out there that won't create products for the ocf ecosystem until there's a turnkey solution akin to Ayla networks because they lack the technical competence to do anything more hands on. I'm gonna attempt to answer the questions you raised at the end of your message: >Proposed maintainer: ondrej wants to be the maintainer. >What will be in this codebase and why it should be part of iotivity: hopefully >I addressed this sufficiently in my first paragraph, but please let me know if >you feel that I haven't. >Proposed name: IIRC the "official name" that I've seen thrown around is "coap >native cloud" although I'm personally not the biggest fan of that name. Worst >case scenario, we can always take a page out of the serverless community and >just call it "Jeff". If you're interested, I'd love to whip up a slide deck and get on a call with the relevant stake holders and decision makers to discuss this in greater detail. I think if we can get aligned on the high level goals and foundational assumptions for our respective arguments, that the technical decisions will become much more obvious and less controversial. Best regards, Scott From: Thiago Macieira Sent: Thursday, May 31, 3:38 PM Subject: Re: [dev] coap-go repository To: [email protected]<mailto:[email protected]> On Thursday, 31 May 2018 11:55:28 PDT Ondrej Tomcik wrote: > Who said it is only TCP implementation gentlemen? I was talking about TCP > Cloud. Or as Gregg wrote, let's call it differently. I am using this > strange name just because that's how the POC in the /iotivity/cloud was > named by the Samsung. Actually, it's resource directory and account server. > > Back to library. > It's coap library supporting both UDP and TCP+TLS. Development already in > progress. Two wrongs don't make a right. Please explain then what will be in this repository, why it should belong in IoTivity, who will be responsible for it (that is, who the Maintainer will be), and propose a proper name for it. I think I've asked you to explain the goals at least three times and I still don't get what you're trying to do. Don't write a short paragraph. Please take the time to explain. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
