[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-devel
Subject:    Re: [E-devel] efl net classes... why is this not ijn a shared parent class or interface?
From:       Carsten Haitzler <raster () rasterman ! com>
Date:       2017-09-17 9:13:22
Message-ID: 20170917181322.2242bb7f5967f7abc2d613a9 () rasterman ! com
[Download RAW message or body]

On Sun, 17 Sep 2017 00:22:34 -0300 Gustavo Sverzut Barbieri
<barbieri@gmail.com> said:

> agreed and I'll fix, but need some weeks so I can get to it.

no problems. i'm finding some other "niggles" i'm also fixing inside... :)

> On Fri, Sep 15, 2017 at 11:32 PM, Carsten Haitzler <raster@rasterman.com>
> wrote:
> > On Fri, 15 Sep 2017 11:24:54 -0300 Gustavo Sverzut Barbieri
> > <barbieri@gmail.com> said:
> >
> >> because I found the number of intefaces to be already too big to start
> >> to create more... so I left them in the class, not in another
> >> interface.
> >>
> >> Efl.Net.Server
> >>  - Fd
> >>     - Tcp
> >>     - Udp
> >>     - Unix
> >> - Ssl (may wrap tcp, udp, unix...)
> >
> > hmmm ssl isn't really practical over udp... right? so i guess putting it in
> > fd parent class would lead to udp subclass inheriting methods we have to
> > nullify (turn into nops/errors) for the ssl specific features. so the only
> > way to share nicely is have an ssl interface that udp and unix share...
> >
> >> but could be changed, sure... like:
> >>
> >>  - Fd
> >>     - Ip
> >>       - Tcp
> >>       - Udp
> >
> > that would fix the tcp vs udp example below indeed.
> >
> >> we'd need to create an efl_net_ip class with little to share.
> >>
> >> as for ssl... I'm trying to remember why I didn't make it a subclass
> >> of Tcp, instead just created an inner server that proxies all calls...
> >> looking at the final code, there is no reason why... but eventually
> >> during early development it couldn't be done and I "forgot" when
> >> things were cleared. (ie: Efl.Net.Server.client_announce got
> >> introduced late, and likely that's what now makes it possible, since
> >> we need to wrap a pure TCP into ssl before announcing it).
> >
> > hmmm yeah. as a final code blbo (api/interface) it just looks... wrong. it
> > does lead to excess code on the "api user" side to deal with specially (you
> > cant just switch to an ssl class and add in the ssl specific setup methods
> > for just that. you have to switch over a bunch of the other methods too
> > that are common).
> >
> >> On Fri, Sep 15, 2017 at 12:12 AM, Carsten Haitzler <raster@rasterman.com>
> >> wrote:
> >> > On Fri, 15 Sep 2017 12:11:16 +0900 Carsten Haitzler
> >> > <raster@rasterman.com> said:
> >> >
> >> > also i spotted:
> >> >         efl_net_server_tcp_ipv6_only_set(server, ipv6_only);
> >> > vs
> >> >         efl_net_server_udp_ipv6_only_set(server, ipv6_only);
> >> >
> >> > same question... ?
> >> >
> >> >
> >> >> why do i need to do stuff like:
> >> >>
> >> >>    if (klass == EFL_NET_SERVER_SSL_CLASS)
> >> >>      {
> >> >>         efl_net_server_ssl_reuse_address_set(server, EINA_TRUE);
> >> >>         efl_net_server_ssl_close_on_exec_set(server, EINA_TRUE);
> >> >>         efl_net_server_ssl_reuse_port_set(server, EINA_TRUE);
> >> >>      }
> >> >>    else
> >> >>      {
> >> >>         efl_net_server_fd_reuse_address_set(server, EINA_TRUE);
> >> >>         efl_net_server_fd_close_on_exec_set(server, EINA_TRUE);
> >> >>         efl_net_server_fd_reuse_port_set(server, EINA_TRUE);
> >> >>      }
> >> >>
> >> >> why are these (and other sibling methods/properties) not in a shared
> >> >> interface or parent class? this seems ... bad. ?
> >> >>
> >> >> --
> >> >> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> >> >> Carsten Haitzler - raster@rasterman.com
> >> >>
> >> >>
> >> >> ------------------------------------------------------------------------------
> >> >> Check out the vibrant tech community on one of the world's most
> >> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> >> _______________________________________________
> >> >> enlightenment-devel mailing list
> >> >> enlightenment-devel@lists.sourceforge.net
> >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >>
> >> >
> >> >
> >> > --
> >> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> >> > Carsten Haitzler - raster@rasterman.com
> >> >
> >> >
> >> > ------------------------------------------------------------------------------
> >> > Check out the vibrant tech community on one of the world's most
> >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> > _______________________________________________
> >> > enlightenment-devel mailing list
> >> > enlightenment-devel@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> >>
> >>
> >> --
> >> Gustavo Sverzut Barbieri
> >> --------------------------------------
> >> Mobile: +55 (16) 99354-9890
> >>
> >> ------------------------------------------------------------------------------
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> _______________________________________________
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > Carsten Haitzler - raster@rasterman.com
> >
> 
> 
> 
> -- 
> Gustavo Sverzut Barbieri
> --------------------------------------
> Mobile: +55 (16) 99354-9890
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster@rasterman.com


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[prev in list] [next in list] [prev in thread] [next in thread]