Hi all,
Updated branch devs/barbieri/efl-io-interfaces with
Efl.Net.Dialer.Http (name agreed with Cedric, I know it's tooooo
long).
It works for GET requests without extra header or proxy, those are
TODO, as well as POST/PUT requests that need the upload part (done but
untested).
As result, efl_io_copier_example.c now supports http sources with ease.
Check it out to see what is implemented regarding events, particularly
headers ("headers,done" is emitted many times if allow_redirects=True,
with 2 methods to retrieve headers, one for last request, one for all
requests; "connected" is also emitted many times if
allow_redirect=True, each with its own status code and
address_remote).
Some optimizations to avoid extra copies/buffers could be used, they
are marked as TODO and will be addressed later in the project.
Next is to make sure POST/PUT works to upload stuff, it may need more methods.
On Thu, Aug 18, 2016 at 2:32 AM, Gustavo Sverzut Barbieri
<barbi...@gmail.com> wrote:
> Hi all,
>
> Updated my branch with a properly working Efl.Io and an initial
> Efl.Net covering TCP client and server.
>
> https://git.enlightenment.org/core/efl.git/log/?h=devs/barbieri/efl-io-interfaces
>
> The TCP is far from complete if you compare with existing ecore_con,
> not to say the other missing protocols (UDP, Unix Local...), but the
> idea is there and I'd like you to review at least the .eo to check
> out the usage, names and so on. There you can see I'm taking the
> advice to avoid "flags" and "enums", using specific properties for
> classes that can use them, like Efl.Net.Socket.Tcp is the only
> providing "no_delay", "cork" and "keep_alive" properties. OTOH all
> filedescriptors will do "close_exec".
>
> "non_block" isn't there yet, likely I'll add these to Efl.Io.Reader.Fd
> and Efl.Io.Writer.Fd, thus being accessible by Efl.Net.Socket.
>
> I'm also thinking about "auto_close" for Efl.Io.Closer, so objects can
> be told to automatically close if they were deleted.
>
> With the current API a "netcat" is trivial, as is an "echo" server.
> Still not so trivial is to do interactive chats where you send a
> command, wait for an answer, then send something else. I'll cover
> these later as in my plan/roadmap is to finish Efl.Network.Url, which
> I plan to move to these new interfaces... fortunately HTTP is not a
> chat-like protocol... at least at the high-level when using cURL :-)
> but it's much more complex and well defined than a simple TCP socket,
> so it may expose some some needs/failures which will be reviewed.
>
> Once the Efl.Network.Url is okay, I'll be back to TCP/UDP/UNIX/SSL and
> replace most of my code with pieces of ecore_con.c (it was too tied to
> old design to be used as-is, so needs more effort). This will include
> an asynchronous name resolution (similar to ecore_con_info) and
> connect.
>
> As a final note, these are using the Eina_Slice/Eina_Rw_Slice and
> Eina_Error-returns as discussed in other threads, but I'm taking them
> as temporary/under-review. So far they're working well, but shall the
> consensus be to change, I'll do that before 1.19 release.
>
>
>
>
>
>
> On Tue, Aug 16, 2016 at 1:14 AM, Gustavo Sverzut Barbieri
> <barbi...@gmail.com> wrote:
>> And finally it works!
>>
>> https://git.enlightenment.org/core/efl.git/log/?h=devs/barbieri/efl-io-interfaces
>>
>> you can see the example is able to transparently copy from stdin to
>> stdout/stderr, it can copy to/from files... without any special code
>> in the example itself.
>>
>> That is, when I add Efl.Net, we can copy to/from some socket, be it
>> TCP, UDP or even an URL created with libcurl as backend.
>>
>> Raster, take a look and see that the events you want, such as "data"
>> (analogous to ECORE_CON_*_DATA events) or "line" are emitted there.
>> This is particularly interesting for ease of use, debug and support of
>> legacy APIs.
>>
>>
>> On Mon, Aug 15, 2016 at 2:35 AM, Gustavo Sverzut Barbieri
>> <barbi...@gmail.com> wrote:
>>> Hi all,
>>>
>>> Updated with more details, Efl.Io.Copier and Efl.Io.File are mostly
>>> done (although untested -- will focus on these tomorrow). I should add
>>> some simple subclasses from these Efl.Io to help testing, like Stdin,
>>> Stdout, Stderr, Null (/dev/null-like) and Zero (/dev/zero-like).
>>>
>>> As you can see in Efl.Io.Copier, it's the one doing "data" events like
>>> Ecore_Con and Ecore_Con_URL did, but in a general way so whatever
>>> implements the Efl.Io.Reader interface could do those (my plan is to
>>> use a discard output like Efl.Io.Null to get the same effect). It is
>>> doing line-buffered output as well, with configurable multibyte binary
>>> delimiter.
>>>
>>>
>>>
>>> On Sat, Aug 13, 2016 at 5:05 AM, Gustavo Sverzut Barbieri
>>> <barbi...@gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> Following the discussions from Eina_Slice and Efl.Io interfaces, I've
>>>> started to code as you can see at:
>>>>
>>>>
>>>> https://git.enlightenment.org/core/efl.git/log/?h=devs/barbieri/efl-io-interfaces
>>>>
>>>> I'll keep following with my preferences of Eina_Slice (instead of
>>>> Eina_Binbuf) and fine-grained Efl.Io.* interfaces (instead of a single
>>>> one that does all operations). It's a bit more work, but it's easier
>>>> to sed & fix compiler errors if we decide to go in the other
>>>> direction.
>>>>
>>>> The code compiles, but I did not test the new objects yet. With the
>>>> existing code (if it works) it would fulfill memory<->file cases.
>>>>
>>>> Then it would be a matter of adding Efl.Net.Socket based on
>>>> Efl.Io.*.Fd that makes sense (ie: reader, writer, closer). It would be
>>>> about implementing finalize for Dialers (or an explicit connect() as
>>>> requested by raster).
>>>>
>>>> For Efl.Net.Http.Client (ecore_con_url), it would also expose Efl.Io.*
>>>> interfaces, but since cURL handles the actual fd, it would not be
>>>> based on Efl.Io.*.Fd. But to the end user, the expected reader,
>>>> writer, closer will all work like expected, being able to use
>>>> Efl.Io.Copier on them to download/upload stuff to/from files or
>>>> memory.
>>>>
>>>> BR,
>>>>
>>>> --
>>>> Gustavo Sverzut Barbieri
>>>> --------------------------------------
>>>> Mobile: +55 (16) 99354-9890
>>>
>>>
>>>
>>> --
>>> Gustavo Sverzut Barbieri
>>> --------------------------------------
>>> Mobile: +55 (16) 99354-9890
>>
>>
>>
>> --
>> Gustavo Sverzut Barbieri
>> --------------------------------------
>> Mobile: +55 (16) 99354-9890
>
>
>
> --
> Gustavo Sverzut Barbieri
> --------------------------------------
> Mobile: +55 (16) 99354-9890
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
