Ondrej, I also share your concerns with the current state of the iotivity cloud, but I have a slightly different opinion on how those concerns should be addressed, and I'm interested in hearing your opinion on it.
I'd argue that the only "official" part of the OCF cloud should be the part that implements the actual device<=>cloud interface since API's age better than infrastructure. Technical decisions like which messaging systems and databases to use shouldn't be hard coded, although it's probably a good idea to have an example where everything is already set up to provide an introduction and reference implementation. If the cloud interface was written such that any interactions with the messaging/DB/auth were performed by end-user-written handlers or some other clean abstraction (like gRPC?), it'd be easier for vendors to integrate OCF cloud messaging into their existing infrastructure. I guess that would function as an alternative to the HTTP proxy that you're proposing. It'd also largely make the concerns scaling/reliability/updatability/availability out of scope, which I'd argue is preferable since those concerns are more within the bailiwick of the CNCF than the OCF. Speaking of the CNCF, if you want to see a project that utilizes a fair number of CNCF projects that would be able to utilize my proposed cloud interface, and has been placing a large emphasis on scaling/perf/availability, check out https://github.com/mainflux/mainflux Regards, Scott From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Ondrej Tomcik Sent: Sunday, April 29, 2018 3:18 AM To: Max Kholmyansky <max...@gmail.com> Cc: iotivity-dev@lists.iotivity.org Subject: Re: [dev] Activity of cloud maintainers Hello Max, my list is ordered already by priority. (Documentation is not lowest priority but I wanted to mention it explicitely. ) So scalability and reliability is for us number one, together with HTTP proxy, which must be there to be able to use IoTivity Cloud component from other backend components in convinient way. BR Ondrej On 29 Apr 2018, at 08:31, Max Kholmyansky <max...@gmail.com<mailto:max...@gmail.com>> wrote: Hi Ondrej, This is a very good suggestion. One thing I want to stress: from the open source community perspective, there is no value in OCF compliance, unless the software cannot be used in production. Server-side software must be scalable and reliable, and support modern deployment and load balancing technologies. So IMHO we must put scalability and reliability before the compliance. An example of scalability challenge... right now, there is an assumption that the communicating entities ("client" and "server") establish a TCP connection to the same instance of Interface service. This is OK for the proof-of-concept, but hardly acceptable in a production deployment. Regards, Max Max Kholmyansky Software Architect - SURE Universal Ltd. http://www.sureuniversal.com<http://www.sureuniversal.com/> On Sun, Apr 29, 2018 at 1:03 AM, Ondrej Tomcik <ondrej.tom...@kistler.com<mailto:ondrej.tom...@kistler.com>> wrote: I am glad that you replied Thiago. Just to provide you an overview of a roadmap, or how we as a Kistler see the IoTivity Cloud further development: - HTTP proxy @ communication between IoTivity Cloud and other product components through HTTP, fully compliant with a OCF specification - Cloud enabled @ current Cloud system is not scalable nor reliable. Currently you cannot restart component (e.g. rolling update or just node restart would drop your db). Goal would be to redesign a communication between the Cloud components and a way how it manipulates with a data, to support availability, reliability and mainly scalability. - Resource shadow @ device shadow is a well-known term in a IoT world. We have a PoC of a resource shadow already implemented, so we would start with OCF specification proposal. - Documentation and maintanance If community agrees, let's start. BR Ondrej Tomcik On 27 Apr 2018, at 21:58, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: On Friday, 27 April 2018 00:37:44 PDT Ondrej Tomcik wrote: I would propose to change current list of maintainers. They are inactive and it is not acceptable in open source project. If there are no objections, we'll do that. For anyone willing to object: your objections must come with a solution to Ondrej's problems. -- Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com> Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
