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
