Hello Scott, 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. My concerns are mainly about an inactivity of the IoTivity Cloud subproject, sometimes about "in/activities" of a whole IoTivity project as well - but that's a different topic :). So I would say that if you share my concerns about current inactivity but the way how you would revive the project is slightly different, that's great, let's discuss 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. I assume that now you here writing only about the OCF specification for the Cloud part. Technical decisions doesn't have nothing to do with the specification. Architecture and a design of the OCF Cloud should be agnostic to databases, messaging systems, ... as you wrote. If you meant implementation details of the IoTivity Cloud, I don't agree. IoTivity Cloud should use specific messaging system and database. It should be programmed in a way that it might be exchanged, but that's more an implementation detail rather than a future design of a system. If you would implement the IoTivity Cloud in a way that users can't use it out of box - they firstly have to properly integrate it with their messaging system and db by touching internals of the IoTivity Cloud, it would have same number of users as it has now. (I would say - 1). Reference implementation != production ready system. 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 If I understand you, I would say that users of the IoTivity Cloud won't be interested in writing handlers for communication between IoTivity Cloud Components. In my opinion, they need a system which works out of box, can scale, is secure and reliable, provides async state events of the Cloud system and connected devices and end-user's components can issue commands in a standardised way - HTTP, not Java Native IoTivity SDK. HTTP proxy is already in the IoTivity Cloud, but not finished. Goal is to use it only for issuing of commands towards IoTivity Cloud Interface. State events and async operations should come back in form of messages. And as you wrote, scaling/reliability/... are within the bailiwick of the CNCF. It has nothing to do with OCF. BUT it has to do with the IoTivity. Somehow, I am not completely sure if we have a same opinion or not :) Regards, Scott BR Ondrej From: [email protected] [mailto:[email protected]] On Behalf Of Ondrej Tomcik Sent: Sunday, April 29, 2018 3:18 AM To: Max Kholmyansky <[email protected]> Cc: [email protected] 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list [email protected]<mailto:[email protected]> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
