OK. For a time being we can create tickets for these protocol. We can figure it out from where we can port. :)
On Tue, Mar 14, 2017 at 10:13 PM, Gedare Bloom <ged...@rtems.org> wrote: > On Tue, Mar 14, 2017 at 12:08 PM, Joel Sherrill <j...@rtems.org> wrote: >> >> >> On Tue, Mar 14, 2017 at 10:22 AM, punit vara <punitv...@gmail.com> wrote: >>> >>> Can I port MQTT from here ? >>> >>> >>> https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/net/lib/mqtt >>> >>> It has Apache licence. Where do I possibly need to add files ? Any >>> suggestion ? >>> >> Why would Zephyr want their code to support multiple RTOSes? Would >> we end up with something that has long-term life as an RTEMS option? >> > Apache License is a bit of a pain to use if we need to modify the > upstream source, especially if the upstream will not accept changes. > I, like Joel, am more concerned about the latter in case we need to > adapt the upstream for easier porting and maintenance. > >>> >>> -- PV >>> >>> On Tue, Mar 14, 2017 at 7:50 PM, Joel Sherrill <j...@rtems.org> wrote: >>> > >>> > >>> > On Tue, Mar 14, 2017 at 8:56 AM, Gedare Bloom <ged...@rtems.org> wrote: >>> >> >>> >> On Tue, Mar 14, 2017 at 1:26 AM, punit vara <punitv...@gmail.com> >>> >> wrote: >>> >> > Hi >>> >> > >>> >> > I think RTEMS don't have any IoT protocol so I propose we should >>> >> > implement at least two important IoT protocols >>> >> > >>> >> > 1. MQTT >>> >> > (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html) >>> >> > 2. CoAP (http://coap.technology/) >>> >> > >>> >> Why are these 2 important? >>> >> >>> >> The problem to avoid is adopting a network protocol too early, because >>> >> there is always a bunch of competing ones, and in the end only a >>> >> handful will survive in the long term. >>> > >>> > >>> > MQTT is an OASIS standard which is a good sign. It also has multiple >>> > implementations >>> > already with this one from the Eclipse Foundation looking very promising >>> > and >>> > appropriate for RTEMS. >>> > >>> > https://www.eclipse.org/paho/clients/c/embedded/ >>> > >>> > CoAP also looks promising since it has an RFC. And promising >>> > implementations >>> > to investigate. >>> > >>> > http://coap.technology/impls.html >>> > >>> > https://github.com/obgm/libcoap is dual licensed as GPL and BSD (why?). >>> > >>> >> >>> >> >>> >> > >>> >> > What's your opinion on this ? :) >>> >> > >>> >> This may be a good idea. What is the state of industry and of >>> >> standardization in this space? Are there open-source reference >>> >> implementations with a useful (BSD/MIT) license? >>> >> >>> > >>> > I think those two are worth porting. There are already other ports to >>> > embedded >>> > environments so RTEMS should join the list. >>> > >>> > The effort would have to get the RTEMS specific configuration and >>> > adaptation >>> > code upstream, add RSB recipes, and examples with documentation. I would >>> > honestly expect the ports to be easy enough where more work needs to be >>> > identified. :) >>> > >>> > --joel >>> > >>> >> >>> >> Gedare >>> >> >>> >> > >>> >> > Regards >>> >> > Punit Vara >>> > >>> > >> >> _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel