Actually I am very aware of Open AT, that was a poor wording on my side to say « Linux [...] the OS that Sierra modules are running ». The plan is to Open Source the set of tools allowing to develop for Linux platforms, since this is where there is the most interest for the M2M community at large. Please also note that there are many things in Koneki that are not directly related to « actual » development, and thus are not really related to Linux, OpenAT, Lua, or whatever: support to manipulate protocols, simulators for client/server communication, utilities to help configure M2M devices, …
I am not sure I understand your concern about Lua support being a restriction? C development, if this is why your talking about, is of course still possible, we just put a bit more effort on the Lua stuff because it opens the door to great tooling (e.g. LuaRPC to remotely configure the target, Lua packaging mechanism –LuaRocks– to package and provision applications, …)
Thanks very much for your feedback, and I hope I have clarified things
You say, « Sierra Wireless’ initial seed will be largely Linux oriented, since this is the OS that Sierra modules are running. »
You seem unaware of the Sierra Wireless (formerly Wavecom) Open-AT modules, then?
See: https://forum.sierrawireless.com/viewtopic.php?f=34&t=5472&p=22744
See also: http://tinyurl.com/69r857u
I think the Lua focus will greatly restrict the usefulness at the embedded end – I don’t think that’s a good thing?
Hi Andrew,
Actually I am very aware of Open AT, that was a poor wording on my side to say « Linux [...] the OS that Sierra modules are running ». The plan is to Open Source the set of tools allowing to develop for Linux platforms, since this is where there is the most interest for the M2M community at large. Please also note that there are many things in Koneki that are not directly related to « actual » development, and thus are not really related to Linux, OpenAT, Lua, or whatever: support to manipulate protocols, simulators for client/server communication, utilities to help configure M2M devices, …
I am not sure I understand your concern about Lua support being a restriction?
C development, if this is why your talking about, is of course still possible, we just put a bit more effort on the Lua stuff because it opens the door to great tooling (e.g. LuaRPC to remotely configure the target, Lua packaging mechanism –LuaRocks– to package and provision applications, …)
Thanks very much for your feedback, and I hope I have clarified things