My thinking has always been that there is a current Espruino architecture in place that @Gordon designed and built to support a number of partner networking devices. I too believe that there may be alternative designs available but my thinking at this stage of the project is to adhere to the current designs in place. The alternative would be to re-architect and re-work existing designs which (opinion) would delay the availability of a good ESP8266 port.
My vote would be to get as much of the ESP8266 port working as possible adhering to the existing designs and then ... when the port has reached a stage that some might call "complete" ... then we can turn our attention (if needed) to suggestions for core Espruino internal re-designs.
Now ... as we go through the ESP8266 porting work, things like you have said are golden and should not be lost but instead, perhaps, captured as new "Issues" for subsequent evaluation and addressing.
It took me a ton of time to get my mind around how the networking subsystems worked ... but once I did that, the actual amount of design and coding needed to "integrate" with the existing design wasn't horrible. That leads me to believe that if future rework was needed at the ESP8266 level because of a change to the way Espruino core was driving it, that wouldn't be radical surgery.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
My thinking has always been that there is a current Espruino architecture in place that @Gordon designed and built to support a number of partner networking devices. I too believe that there may be alternative designs available but my thinking at this stage of the project is to adhere to the current designs in place. The alternative would be to re-architect and re-work existing designs which (opinion) would delay the availability of a good ESP8266 port.
My vote would be to get as much of the ESP8266 port working as possible adhering to the existing designs and then ... when the port has reached a stage that some might call "complete" ... then we can turn our attention (if needed) to suggestions for core Espruino internal re-designs.
Now ... as we go through the ESP8266 porting work, things like you have said are golden and should not be lost but instead, perhaps, captured as new "Issues" for subsequent evaluation and addressing.
It took me a ton of time to get my mind around how the networking subsystems worked ... but once I did that, the actual amount of design and coding needed to "integrate" with the existing design wasn't horrible. That leads me to believe that if future rework was needed at the ESP8266 level because of a change to the way Espruino core was driving it, that wouldn't be radical surgery.
(all opinions)