On Fri, Aug 5, 2016 at 1:53 PM, Cedric BAIL <cedric.b...@free.fr> wrote: > I think your example does illustrate quite well while asynchronous API > with events is tricky for users to get right. I think you do set your > error handler a little bit to late. What if during finalize the server > is unable to listen to that port for whatever reason ?
AFAIU the finalize would return NULL, failing the object creation. (which my example fails to check :-D) >> - added adopt(fd) to Efl.Net.Socket and Efl.Net.Server, should be >> usable when fd was created elsewhere, like systemd or different >> libraries. > > Hum, I would prefer that to stay internal. Ecore_Con today has a flag > for handling systemd passing, I do prefer that mecanism. eventually we'll get fds from other sources, then we'll always need something like that. also, when the server will create a socket, it will use that in the constructor... >> - addresses are all strings now. Dialer provides a 'resolved' event. >> >> - removed the "type" enum, each specific class (ie: >> Efl.Net.Socket.TCP) will create the correct fd. There are flags >> property to specify whatever else (like: tcp_cork and tcp_nodelay), >> which will result in setsockopt(). > > Do you plan to have the same for ssl ? yes, that's how almost all frameworks work. I never saw any doing the "upgrade" we did, they just document a pattern where you create an object using an existing connection (like our adopt()). We could provide something out of the box as in ecore-con, or just document the pattern as they do. for proxy it's mixed, some use a proxy constructor while others set a proxy agent as an option. I'll review these in depth after we're settled with the basics. the good approach about specific classes is that you can more easily provide properties that make sense and only for connections that do make sense, like SSL for TCP makes sense, while does not for UDP, where DTLS would do. I also do not think proxy makes sense for Servers, just Dialers... ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
