On Thu, Aug 11, 2016 at 2:21 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Wed, 3 Aug 2016 01:29:39 -0300 Gustavo Sverzut Barbieri
> <barbi...@gmail.com>
> said:
>
>> On Tue, Aug 2, 2016 at 5:00 AM, Carsten Haitzler <ras...@rasterman.com>
>> wrote:
>> > On Mon, 1 Aug 2016 00:50:31 -0300 Gustavo Sverzut Barbieri
>> > <barbi...@gmail.com>
>> [...]
>> >> struct Efl.Net.Address {
>> >> family: Efl.Net.Family;
>> >> address: union { in, in6, bt... };
>> >> }
>> >
>> > are you sure this shouldn't just be a string above for address? and as
>> > onefang said - the string can tell us what we need. it can just be a domain
>> > name of an ipv4 addr or an ipv6 addr and so on... ? the actual
>> > representation like this should be internal and not at any API level. at an
>> > API return a stringified thing. set the destination address, get it back
>> > as-is with a string name. request a result and once resolve is done
>> > (callback or promise) you can get the string resolution of the address. eg
>> > ipv4 addr string or ipv6 addr string for example. this just de-complicates
>> > API across bindings to not need a union (a bit of an ugly issue) and who
>> > really deals with addresses at this format/level?
>>
>> No hard opinion on string versus struct. The good part of strings is
>> that it's easy to extend without going into unions and the likes. But
>> it doesn't allow compile-time checks and simple switch/if on the
>> family (which can be solved by using some functions to parse or check)
>>
>> If you think a string is good to go, I'll change to that.
>
> i totally get the point about structs/compile time checks etc. but in this
> case
> i think the flexibility and simplicity of a string will far outweigh the
> downsides. reality is that 99% of usage will be like connecting to
> "myserver.com" Or a simple ip address on a local network which is kind of hard
> to get wrong. :)
ok, this is more flexible and I already changed in my local branch...
I also liked the idea to make Efl.Net.Http.Client use that same
property to give the url.
>> >> struct Eina.Blob {
>> [...]
>> > this is a big problem for bindings. a big fat "no - find another way". no
>> > function pointers in structs or parameters to methods etc. no void *'s
>> > (reserved for base eo classes only). use eina_binbuf - a list/array or
>> > chain of binbufs or perhaps something else.
>>
>> see my other emails, the idea is to allow different "free" for
>> different kinds of memory (ie: mmap) and windowing/slicing (ie: line
>> of a file).
>>
>> It's not a hard requirement either, just my efficiency advice after
>> invested lots of time to test this use case with Soletta.
>
> i think this would be then best solved at the binbuf level - allow a binbuf to
> be a region of a mmaped file (eina_file?) and handle referencing etc. etc.
> there.
See my other email after talking to Tom, the idea to convert from
reading-and-forwarding data to user won't be used. Instead we'll
notify there is something to read and users will call a "write()"
method to/from where they want, can be a binbuf, mmap, etc.
>> > how do we deal with resolving? a promise? an event callback? we have
>> > multiple stages here. first a resolve (async) then a connect (async) then
>> > finally we are established.
>>
>> In the current proposal it's not there, it would be another class that
>> resolves the string to an Efl.Net.Address and that could be with a
>> promise.
>>
>> That could be more cumbersome to use, but would remember people to
>> cache the resolved address.
>>
>> Node.js and Qt both use an event to notify they were resolved.
>
> i think you should do that too. use a resolved event, and always automatically
> resolve for the user as anything else is painful to use to have to break up
> resolving and then connection into separate things. let people know what
> events are/have happened along the way and *IF* they provide the right info -
> eg a previously stored and resolved ip address then they can skip stages in
> the
> connection (still provide a resolved event but call it immediately on connect
> as the result is known already).
ok, also done in my local branch, should send some update next week
(right now working into another branch for ecore-con).
>> >> @property internal_fd {
>> >> [[the internal file descriptor (use with caution!)]]
>> >> /* it seems the usage is to steal the fd to do something
>> >> * else or set some flags. If so we could expose some
>> >> * primitives such as fcntl_add(type, flags) and
>> >> * fcntl_del(type, flags) as well as a destructor that
>> >> * will return the stolen fd (destroys the object and
>> >> * keeps fd alive).
>> >> */
>> >> get @virtual_pure {
>> >> }
>> >> values {
>> >> fd: int;
>> >> }
>> >> }
>> >
>> > this has issues possibly on windows. fd's don't quote behave the same way
>> > here. can we avoid this? if we need to do deep down ugly things with the
>> > fd... can we just support them with the API? like fd passing on local unix
>> > sockets. have our api deal with sending and getting fd's as a specific send
>> > method and an input event. i get why you have this - as a "way out" for
>> > when we don't support something. this is kind of bad for bindings though
>> > and portability. :(
>>
>> don't get me wrong, I tried to justify to not have it there!
>>
>> I just put it here because Ecore_Con.h provides that and from my
>> investigation, empc is the only user (gets the connected fd and
>> handles the socket to mpd library:
>
> that's kind of silly :( then you cant do proper buffering etc. and portability
> is hurt.
portability is indeed hurt, but it's the only way since other POSIX
libraries will take over your accepted socket. Like done for the mpd.
>> https://git.enlightenment.org/apps/empc.git/tree/src/bin/empdd.c#n828
>>
>> Then in this case we could provide a way to steal the fd and delete
>> the client, keeping the fd alive.
>
> i dislike this. i am ok with a "legacy api only" function that can steal out
> the fd.. but in eo? i'd rather this be as portable as possible. mpd etc. libs
> then probably should provide a virtual i/o interface instead.... that would
> make
> it portable. :)
you can't make it portable since the users are not portable. Here mpd
is only using ecore-con-server to implement Efl-friendly (ecore)
bind/accept. Everything else is up to the library.
[...]
>> like resetting the address... once the connection is done, this
>> operation is not supported.
>
> i agree that THIS would be silly (to change address once connected). i was
> thinking that you may want to respond to a resolution event though. e.h. set a
> name, on resolved event go "oh dear. that's wrong! i know the ip address
> should not be this" and then try some fallback. with the same connection. It's
> simple enough to have the functions return a bool and return a fail if it's
> not
> possible to change this aspect. document them as such. i would actually just
> document them as having no effect until a connect() method is called. a NEW
> connect() will fail until a disconnect() is called. you can only change these
> parameters when the connection is not connecting or connected (you must
> disconnect first). ...
ok, I'm following with these logs/docs approach.
>> >> error: int; [[errno]]
>> >
>> > i really don't like error as an int. really don't. a proper enum and/or
>> > struct with fields like enum for error type and maybe a string for error
>> > extra info (human readable from perror() style?)
>>
>> is Eina_Error ok?
>
> errr... thats horrible., it's a global TLS. ugh. :( make it an enum :
Okay, so the new trend is to convert all possible errors to
context-specific errors? In the old days it was about eina_errors...
:-)
will be kinda of a pain to map all possible errnos to enums, but i can
do it. (the other approach was to register all errnos at load time and
do a simple conversion as generic function eina_error_from_errno kinda
of thing).
>> It's easy to create your own list if you wish, by listening to
>> "connection" event and append to eina_list.
>>
>> The only user I found (eeze_scanner) already have a hash, so could do
>> a foreach() there.
>
> it just saves the clients from doing their own client store since the server
> obj is already doing this anyway... :)
I'll try to avoid exposing these, let's see how it goes. Likely the
server will be the parent of clients, so you can look the object
children and see if you're lazy :-D
>> > 1. missing anything to do with SSL. events for certificates, validity,
>> > being
>> > able to register certs, verify etc. etc. etc. you touch on this in analysis
>> > of ecore_con server/client.
>>
>> it's written on the first part of the email :-) I'll come to this, but
>> let's first get the basics right and the SSL must follow the pattern.
>
> yeah.. but it's not there. so needs doing. :) it adds quite a lot of things.
> :(
but given how much the basics changed, it would be a waste of time
mixing SSL into it right now. Also from
https://gist.github.com/barbieri/ed77c1e829a6e684dd736a771d6732d1 you
can see they are mostly unused in our codebase. Sure we need to do
them as we cannot break legacy, but can wait bit more.
>> > 4. how do you disconnect a client? del the client object you see in the
>> > event info?
>>
>> yes. I see that other tools offer some "graceful shutdown" and
>> "immediate abort". The graceful shutdown will stop reading and will do
>> the actual close once all pending data is sent. The immediate abort
>> will ignore pending stuff.
>
> hmm. very good question. how do you handle this? hmmm.
>
>> we can do 2 distinct methods if you wish, or we can let the user deal
>> with graceful shutdown on his own by using the events (or promise as
>> cedric wants).
>
> or... have a "shutdown mode" for an object. the default would be graceful
> (stop
> reading and flush all buffers already queued for writing). this would be the
> nicest in that it preserves logical behaviour. if your wrote something it WILL
> get sent even if you delete the object. just the delete is a task/event to do
> after the writes you called are done. it gives the appearance of
> order-of-operation and no nasty surprises.
>
> the del should not necessarily BLOCK. it should just queue the deletion in
> this
> case...
>
> then have a "no do it right now" mode which abandons any unwritten/flushed
> writes and kills it off right now. this mode you'd change prior to a del if
> you
> really wanted this. this guarantees that other than some other accounting
> needs
> which may hold refs to the obj, it'll be gone after the del along with any
> buffered data not written yet.
I'll follow with a close() that aborts everything that is pending,
then when we convert existing users in our codebase to the new API I
can see what's the most used operation mode. Will also do some
realistic examples (ie: send goodbye and close the connection).
with the design change away from internal buffering (ie: using
Efl.Io.Writer.write()), I need to do caching on my own, in that sense
I will know for sure when I have nothing else to do and can close it.
>> > 9. no way to GET the current buffer status of a connection you made to a
>> > server. e.g. how much data is buffers and not sent yet (not sent to
>> > kernel).
>>
>> indeed, you'd have to keep that information elsewhere. But it's a
>> simple getter, so we can add if wanted.
>
> yeah. a simple getter to get # of bytes or # of packets not set yet etc.
with the new design this isn't needed anymore as there is no internal buffering.
>> > what should we do about things like mqtt, mq/zeromq, ocf/oic - they belong
>> > in another interface layer? http is a bit different too due to its nature.
>> > websockets i can see fitting underneath the above, but not real http itself
>>
>> mqtt and the others are all PITA to get all the quirks right... pretty
>> much like http they look simple to implement the basics, but then the
>> other peers rely on bug-compatibility with mainstream projects such as
>> mosquitto, iotivity... So implementing on top of pure socket is a
>> major work, would be simpler to just do bindings for "de facto
>> standard" libraries.
>
> oh i wouldn't want to re-implement the protocols on top of raw sockets. hell
> no.
> i was thinking that efl net work provide a layer that would offer these
> (mq/mqtt/oic/ocf/allseen?) as a transport protocol layer... the problem is
> this
> level of api is very dumb - it doesn't understand much but a blob of bytes
> going
> in or out either as a stream or as a series of packets. the above i would
> absolutely expect would be implement on top of a library layer that dealt with
> the details and we're just providing a single "nice abstract class/interface"
> for doing not just tcp/udp and local unix sockets but also these others...
> since we're doing http - how would these others fit into this design? would
> they? should they? there is value in these being wrapped by eo objects so they
> can nicely sit in an object tree and be managed like everything else... :) i
> don't say we do this NOW... but i say we should consider these in our design
> and not make something that might preclude them unless it really is just
> insane
> to support them.
after looking at both, talking to tom and did some local tries, I
believe with the Efl.Io.Reader and Efl.Io.Writer interfaces they can
be made the same.
Efl.Net.Http.Client would be just a new Efl.Net.Tcp.Dialer... (should
we call Efl.Net.Http.Dialer?) you give it the address as you'd for any
dialer, but internally it would use libcurl instead of plain socket.
After it's created, depending on the operation method you get the
proper behavior (ie: GET won't allow write() method).
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
