{"action":"created","issue":{"url":"https://api.github.com/repos/micropython/micropython/issues/876","labels_url":"https://api.github.com/repos/micropython/micropython/issues/876/labels{/name}","comments_url":"https://api.github.com/repos/micropython/micropython/issues/876/comments","events_url":"https://api.github.com/repos/micropython/micropython/issues/876/events","html_url":"https://github.com/micropython/micropython/issues/876","id":44067012,"number":876,"title":"Framework for coherent eth/wlan drivers on pyboard","user":{"login":"dpgeorge","id":6187689,"avatar_url":"https://avatars.githubusercontent.com/u/6187689?v=3","gravatar_id":"","url":"https://api.github.com/users/dpgeorge","html_url":"https://github.com/dpgeorge","followers_url":"https://api.github.com/users/dpgeorge/followers","following_url":"https://api.github.com/users/dpgeorge/following{/other_user}","gists_url":"https://api.github.com/users/dpgeorge/gists{/gist_id}","starred_url":"https://api.github.com/users/dpgeorge/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dpgeorge/subscriptions","organizations_url":"https://api.github.com/users/dpgeorge/orgs","repos_url":"https://api.github.com/users/dpgeorge/repos","events_url":"https://api.github.com/users/dpgeorge/events{/privacy}","received_events_url":"https://api.github.com/users/dpgeorge/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/micropython/micropython/labels/ports","name":"ports","color":"bfe5bf"},{"url":"https://api.github.com/repos/micropython/micropython/labels/rfc","name":"rfc","color":"FF66CC"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":45,"created_at":"2014-09-26T14:23:32Z","updated_at":"2015-06-27T15:36:06Z","closed_at":null,"body":"We need a standard way of using internet modules on the pyboard that is powerful, extensible and easy to use.  Powerful means being able to attach an ethernet and wifi module at the same time (and possibly multiple ones of these); extensible means we should be able to add new drivers without changing existing ones; easy to use means it should behave as expected for someone familiar with the Python socket module.  Note that higher level abstractions (like http servers) can be built upon a proper functioning socket interface.\r\n\r\nLet's first briefly review how things are done in Python and on a POSIX system.  Python has the socket module which allows you to make socket objects, and do things like gethostbyname:\r\n```\r\nimport socket\r\nip = socket.gethostbyname('micropython.org')\r\ns = socket.socket(socket.AF_INET)\r\n```\r\nThis is just a wrapper for the underlying POSIX calls.\r\n\r\nThe above calls don't know anything about the underlying internet device (be it eth0 or wlan0 for example).  That, and the configuration of an IP address, is left up to the operating system.\r\n\r\nOn the pyboard, uPy *is* the operating system, and so we need a way (in Python) to initialise and configure the eth/wlan drivers, and also a way to select which one we want to use for, eg, a gethostbyname call.\r\n\r\nA scenario might be: I have a pyboard with a CC3000 (wifi) and a WIZnet (eth) module connected.  I need to initialise them on the correct pins, then perhaps run DHCP on the CC3000, but set a static IP for the WIZnet.  I want the CC3000 to be a server and the WIZ to be a client, and I need to open sockets on both.\r\n\r\nMy proposed solution is to have a \"meta socket\" module which contains a class for each driver that is available.  To initialise a driver, you make a new instance of the associated class.  The instance object then behaves like a CPython socket module, and calling socket on this class makes a socket associated with that driver.  Each driver has its own gethostbytname, etc.\r\n\r\nInitialised drivers also register themselves with the \"meta socket\" module, so, for example, you can get a list of all initialised internet drivers (something like ifconfig on linux).\r\n\r\nI thought about splitting into eth and wlan modules, but I think it makes sense to put all drivers into one module, since the application shouldn't care if a connection is wired or wireless.\r\n\r\nAdding a new driver would be as simple as writing a new class and putting it into the \"meta socket\" module.\r\n\r\nI propose calling the \"meta socket\" module `network`.  An example use would be:\r\n```\r\nimport network\r\ncc3k = network.CC3k(pyb.SPI(1), pyb.Pin.board.Y5, pyb.Pin.borad.Y6)\r\ncc3k.init('myssid', key='secret')\r\n# cc3k now acts like a socket module\r\ncc3k.gethostbyname('micropython.org')\r\ns = cc3k.socket(cc3k.AF_INET, cc3k.SOCK_STREAM)\r\n\r\nwiz = network.WIZnet5k(...)\r\nwiz.init(...)\r\n# wiz also acts like a socket module\r\n\r\nnetwork.iflist() # will return [('wlan0', cc3k), ('eth0', wiz)]\r\n```\r\nComments, thoughts, suggestions?"},"comment":{"url":"https://api.github.com/repos/micropython/micropython/issues/comments/116089597","html_url":"https://github.com/micropython/micropython/issues/876#issuecomment-116089597","issue_url":"https://api.github.com/repos/micropython/micropython/issues/876","id":116089597,"user":{"login":"danicampora","id":7749335,"avatar_url":"https://avatars.githubusercontent.com/u/7749335?v=3","gravatar_id":"","url":"https://api.github.com/users/danicampora","html_url":"https://github.com/danicampora","followers_url":"https://api.github.com/users/danicampora/followers","following_url":"https://api.github.com/users/danicampora/following{/other_user}","gists_url":"https://api.github.com/users/danicampora/gists{/gist_id}","starred_url":"https://api.github.com/users/danicampora/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danicampora/subscriptions","organizations_url":"https://api.github.com/users/danicampora/orgs","repos_url":"https://api.github.com/users/danicampora/repos","events_url":"https://api.github.com/users/danicampora/events{/privacy}","received_events_url":"https://api.github.com/users/danicampora/received_events","type":"User","site_admin":false},"created_at":"2015-06-27T15:36:06Z","updated_at":"2015-06-27T15:36:06Z","body":"> In my list, WiPy development is on this forefront, but I don't see much much of what discussed being implemented there. \n\n\nApart from the things that we already know, what else do you see in the WiPy that doesn't follow what we have discussed?\n\n> On Jun 27, 2015, at 5:08 PM, Paul Sokolovsky <notifications@github.com> wrote:\n> \n> that devs actually stick to the agreed upon convention.\n> \n> Yes, and that's how I hoped that it worked all this time (not one month by now) - that we'll discuss it and come to conclusions, then someone on the forefront of this work will implement it, to serve as actual code template for other ports. In my list, WiPy development is on this forefront, but I don't see much much of what discussed being implemented there. And I don't say that for finger-pointing, it's perfevtly clear that @danicampora has a lot of other important things to do for his port. In the meantime, we get submissions for esp8266 which either need to be ignored, rejected, or reworked. I finally take a step to lay good base for esp8266 by implementing all the latest ideas myself, take a final peek to compare WiPy and pyboard drivers, and see that not only WiPy doesn't implement latest ideas (which is know), but that it's drivers based on older ideas is inconsistent with your original implementation of pyboa rd drivers (which are kinda news).\n> \n> So, \"important [...] that devs actually stick to the agreed upon convention\" doesn't work. And I don't blame devs, I blame conventions, which apparently too tangled and vague, and propose soemthing which can easily fits onto one head, so it will be easy to say what's right and what's not going forward.\n> \n> We should decouple these things: design the API so it's Pythonic and obvious for the user\n> \n> I don't see anything unpythonic in what I propose (again: query params one by one as a baseline), and that can be only more obvious to user than potentially long structures.\n> \n> And that effort only needs to be spent once.\n> \n> No, it will need to be spent again and again going forward, for each newly written or contributed drivers. So, the more complicated scheme we have, the more complicated it will be.\n> \n> What do we actually need to configure?\n> \n> The most generic answer is \"anything\", and mys scheme allows to configure anything. For example, adhoc .patch() method in some driver can be replaced with .config(patch=bytes).\n> \n> How about we design a mock API for wipy and esp8266 independently, with all the required config values that they need/want, and then see where we stand.\n> \n> We already have mock of API there. We already spent a lot of time discussing how it should be, with ~zero outcome so far. I already spent a whole coding session on that, usual outcome of that should be newly implemented or cleaned up functionality, but this time, outcome if zero (well, yet another proposal on how to get it right; well, final on my side). I don't see all that as sustainable or rewarding, given the context of this API (use once and forget), the fact that I don't consider working on esp8266 too beneficial as it stands, that there're other issues in WIP many of which are more important and interesting, etc.\n> \n> So, the only way I see is to do this KISS and get over it.\n> \n> —\n> Reply to this email directly or view it on GitHub.\n> \n"}}