Espurino Source: New files and other artifacts approval process

Gordon,
I am ready to start checking in some of the new work for the ESP8266 runtime port. This means that I will be creating some new artifacts and have made choices for the namings. What process would you like me to follow to check these in with respect to namings. For example, under libs/network we already have an entry called "esp8266" which is for the ESP8266 used as a network module for existing boards. For Espruino running ON the ESP8266, we also need a name under "network". What should we call this entry? I am leaning towards "esp8266board". Do you have any preferences or suggestions?

Neil

Actually I've been meaning to remove that (it's broken, and the JS module is far better now), so have just done so. If you do the git update thing again now it'll remove for you.

esp8266board sounds fine, but actually if you wanted to just use esp8266 now it's free, that would probably be better? After all, we use linux for linux-based systems.

Unless - are the networking libraries for esp8266 called something in particular? For instance if I was porting to lightweight IP on another chip I'd probably stick that stuff in a lwip folder.

Howdy Gordon ... that is GREAT. The ESP8266 APIs for ESP8266 specific. I believe that under the covers some version of "lwip" is used but it is front ended and deeply hidden by the ESP8266 libs. I'd like to use "esp8266" for the directory names so I'll look now.

Thanks Gordon. I resynched and saw the changes you made. Excellent. I have now renamed the ESP8266 networking to be "esp8266". When done, the files should look as shown in the attached screen shot.

1 Attachment

Looks perfect - thanks!

As of today, the ESP8266 networking support is a static class called "ESP8266WiFi". I was about to rework to be a library that would then be accessed (as I understand it) with the format:

var esp8266 = require("<some name>");

I was going to choose "ESP8266" for the name of the networking library but then realized that "ESP8266" is already chosen for use with the ESP8266 piggybacked support. I'm now thinking through what the resolution options may be.

I'd be tempted to just use ESP8266? I actually use ESP8266WiFi as the module name for the piggybacked one, so arguably ESP8266 is less confusing.

just to add here - I'll have to make sure espruino.com/ESP8266 goes to a disambiguation page :)

... Actually, what about just require('WiFi') or even require('network')? Because as you're on the ESP8266 it's obvious what you want.

I can see a time when there are other WiFi devices that run Espruino. Assuming they all use roughly the same API in a WiFi module it would probably be preferable to be able to copy/paste code and have it 'just work'?

+1 to that idea, javascript's so portable, it'd be a shame to have to change your code between boards if there's no real need to.

I agree with both of ya ... however ... what we all need to do now is put our heads together and ask what the "abstract" WiFi API should be?

Assuming that we had a 'require("WiFi")' that returned an object with methods, what then should the method names, signatures and semantics be? If you don't have a basis at this time, I'll go ahead and make one up.

@the1laz ... Would you be interested in community project job? How about you spend an hour or so and make up a spec for the "virtual" WiFi interface and we can implement it against ESP8266 and the other network WiFi boards to come?

Well, there's already a wlan object that pretty much covers it: http://www.espruino.com/Reference#WLAN
Maybe if you add a WLAN.E (or something else, doesn't have to be E) object for anything ESP8266 specific?

I'd look at the existing ESP8266 one (look under 'reference') and copy that - same functions as the CC3000's WLAN object but it uses callbacks.

I think in this case it's probably worth breaking CC3000 backwards compatibility in order to bring that inline with the callback-based approach, and the same could be done for WIZnet too.

I'd say maybe leave ESP8266-specific stuff in the root object? it won't hurt if nobody calls it :)

So what do we think? WiFi, WLAN, or network? net is used for TCPIP already.

I'd say maybe something non-wifi-specific would be good, given there's also ethernet which exposes the same getIP/setIP.

@Gordon I think we need a whole new thread that I would suggest titling:

"Architecture: WiFi generic object interface"

What that thread would cover would be the "spec" for the generic WiFi object that would be exposed to JS and then board implementations such as ESP8266 would then implement that spec.

In my mind, the "WiFi" spec would NOT own any API networking ... it would specifically own WiFi access ... functions that it might expose would be:

• Scan and list the available access points
  
• Connect to an access point as a station
  
• Disconnect from an access point
  
• Become an access point
  
• List the the stations connected to me when I am access point
  
• Drop a station connected to me when I am an access point
  
• Configure DHCP, static IP addresses, default TTL, mDNS, gateway interfaces ... etc etc
  
  

All of these are "WiFi" related and are present to initialize the network arena but aren't network programming so I would keep separate from socketserver functions.

(opinions were rife in this post :-)

just done :) http://forum.espruino.com/conversations/­275060/newest/