Yeah, so do the other polling things on Windows. (Well, mostly sockets. There are some other things supported like named pipes.)
In pyuv there is a pecial handle for those (Pipe) which works on both unix and windows with the same interface.
I guess in order to support this we'd need some kind of abstraction away from socket objects and file descriptors, at least for event loop methods like sock_recv() and add_reader(). But those are mostly meant for transports to build upon, so I think that would be fine.
I see, great! [snip]
Yeah, I see. If we squint and read "handle" instead of "socket" we could even make it so that loop.sock_recv() takes one of these -- it would return a Future and your callback would set the Future's result, or its exception if an error was set.
YEah, sounds like it could work :-) Anyway, I wouldn't be opposed to leaving to APIs just for Python sockets (which I can interact with using a Poll handle) if transports can be built on top other entities such as TCP handles. [snip]
The second model seems more flexible indeed. I guess the SSL transport could be tricky, because while currently Tulip uses the ssl module I have no TLS handle on pyuv so I'd have to build one on top of a TCP handle with pyOpenSSL (I have a prototype here [1]), so object types / APIs wouldn't match, unless Tulip provides some wrappers for SSL related objects such as certificates...
Hm, I thought certificates were just blobs of data? We should probably come up with a standard way to represent these that isn't tied to the stdlib's ssl module. But I don't think this should be part of PEP 3156 -- it's too big already.
Yes, they are blobs, I meant the objects that wrap those blobs and provide verification functions and such. But that can indeed be left out and have implementation deal with it, having tulip just hand over the blobs. Regards, -- Saúl Ibarra Corretgé http://saghul.net/blog | http://about.me/saghul