On Fri, Aug 12, 2016 at 4:47 AM, Carsten Haitzler <[email protected]> wrote:
> On Thu, 11 Aug 2016 10:09:27 -0300 Gustavo Sverzut Barbieri
> <[email protected]> said:
[...] big snippet about protocol specific classes [...]
> hmm i would just say "do http/https" and nothing more. if we want ftp - make
> it
> a new interface. it may re-use curl in the back-end... but make it another
> one.
> what do you think? or should we handle ftp:// too? (seriously... is ftp not
> dead yet?：）） imap, pop, smtp - totally new interfaces etc. for that - maybe
> inherit from efl.net ... but let's not try and make them work here?
>
>> OTOH if we do a specific Efl.Net.Http.Client, then we can be sure of
>> the behavior and expose things like status code in a much nicer way.
>> In this scenario, efl_net_http_client_pipeline_set() (class method)
>> would be more appropriate.
>
> i think this would be much better. separate ftp out as another interface. and
> lets not worry about pop/imap/smtp etc. right now. i actually had no idea curl
> even did these!
okay, so that's good and I'll proceed with that.
will consider the "connect()" (or call()?) for the Dialer interfaces.
>> Indeed, see my Efl.Io.Reader/Efl.Io.Writer. What we could do here is
>> ask the user to create a class implementing Efl.Io.Writer (there
>> should be one based on Eina.Binbuf provided by us), then use
>> Efl.Io.Copier with that.
>
> i am a little bit worried that this is just being overengineered. i have to
> create a efl.net(.socket/http/whatever) then create a reader, inherit the
> class, implement things, just to do a simple
>
> obj = eo_add(class, http_op(POST), addr_set("http://blah.com";), callback_add
> ()...);
> efl_net_send(obj, binbuf_new_from_str("hello world\n"));
>
> u get the idea. i set up the http post connection and then just send my
> content... and i listen lets say to a response callback events. its very
> simple
> this way. if i have to go create io classes and so on what is a few liens of
> code becomes 100's of lines with .eo files and complexity.
>
> i understand the need for performance.... but we shouldn't have it at the
> expense of simplicity.
>
> let's be careful of over-engineering this to the point of unusable for simple
> stuff. let's ensure that we CAN make simple code like above still ... and
> there
> is a way to get performance by writing more code. i'm becoming worried. i need
> to get to the other thread on the io interface. i'm responding "as i go".
>
> but keep in mind the idea of ecore_con with its infinite buffers was to reduce
> work for me writing network code. i didn't want to have to handle writes
> failing
> and doing my own work to handle a partial or full write fail and deal with my
> own buffering. ecoore_con could do that for me. this just takes a bunch of
> headache off my plate and puts it into a useful api. the alternative was
> blocking calls and that was worse.
>
> so whatever we have has to save people work, brain effort and actual lines of
> code. engineering some api perfection is pointless if it just is more work.
>
> i made a mistake of making ecore_con events ecore events in the event stream.
> this was very early in efl and i now realize this was bad and thats a reason
> to
> fix things here with eo and cb's on the objects themselves. but infinite
> buffers as a CONCEPT was right. :)
These will be there, but separated in different classes with specific roles.
As you may remember, when implementing things that need the same
behavior, just different creation methods, you had to re-write the
same block, like Ecore_Exe and Ecore_Con... likely in Ecore_File
that's yet-another.
If all these entities had the same interfaces (read, write, close),
you could handle them as "thin wrappers" to the class that actually
reads and writes, managing buffering.
You even get for free previously special cases "from file" (upload) or
"to file" (download), as in our ecore_con_url methods.
I understand that creating 3 objects as opposed to 1 is kinda of PITA,
but another option is to offer helpers that do that for you.
>> Or the user manually hooks to Efl.Net.Http.Client "write" (from
>> Efl.Loop_Fd) and then calls "write()" (from Efl.Io.Writer).
Also don't ignore this possiblity. It's basically what others like Qt
offers, a signal when you can read/write, then you can explicit
read/write methods without any buffering.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
