On Thu, Aug 11, 2016 at 4:17 AM, Carsten Haitzler <[email protected]> wrote: >> * Eo.Base change to Eo.Loop_User >> * data event: payload: conn (?), size, data. Remove conn, since the >> event callback provides it. > > shouldn't we use.... binbufs? :) same discussion as for efl.net core. :)
could be, as you can see in the rest of the email and further discussions such as the efl_io interfaces, they should indeed look as close as possible, in that sense the event would carry no data, it would be delivered via a Ef.Io.Reader.read() interface method. >> * complete event: payload: conn (?), code (200, 404...). Remove conn, >> since the event callback provides it. > > it's an int.. might it not be best to map this to an enum? the code? it depends. You can see later that currently it is mapped to CURL directly, it's not HTTP specific, thus if you use IMAP or POP you may get different numbers and we'd need to map them all. If we go with a specific-purpose Efl.Net.Http.Client, then yes we can. I've asked Cedric and he likes this approach more, what about you? >> * progress event: payload: conn (?), down/up x total/now (double?). >> Remove conn, since the event callback provides it. Change from double >> to off_t or uint64_t? > > yeah. the double is just silly. off_t or long long/uint64_t ... and should up > and down be different? its either a POST or a GET right? so you dont need > both... no? or can that actually be possible. i guess it can actually.... > never > mind. keep both then. you can get some output from POST... and during GET you can have some lengthy headers. >> * `ecore_con_url_pipeline_set(bool)/get` only usable with http, so >> add that to name? > > add ii name? what would url be doing other than http? ummmm ? that's the thing. In current implementation it's a generic cURL in Ecore, you can do almost everything cURL allows you to, like FTP, IMAP, POP, SMTP... I don't think we need to expose that, as the usage becomes cumbersome.. and really, if we do that, do like a real cURL exposure and point to its CURLOPT_*... since currently we hide and cap some of the features. 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. >> Should change: >> * `ecore_con_url_get(con)` execute a regular fetch (HTTP: GET, FTP: >> download) request. GET is confusing since ressembles HTTP-only, maybe >> rename to 'fetch'? > > how about "connect" .... :) you set up the get/post/whatever as the > transaction > type... :) this would have it have synergy with the efl.net api... :) just the > address is a url rather than a domain name or ip as a string... ? we > should/could use the same read/ events and same send api's for sending/getting > data, BUT there is an added http header payload with events and config for > that... isn't this nicer? ok, but the one in efl.net doesn't have a connect() method. That is done in the finalize. We can do the same here, if we ask the headers/cookies to be added before the eo_add() returns. The inconvenience is that the methods currently take the instance and thus we cannot do C for-loops to load from elsewhere. This could be solved by passing a list/iterator of key-value pairs, or a hash. Or a "hold" method that will not finalize by creating the connection, instead would hold the action, then users can add headers and just then "thaw/resume" to do it. Just may be confusing if executed during an ongoing opertion... should it pause reading/sending data to the connection? >> * `ecore_con_url_head(con)` execute body-less fetch (HTTP: HEAD, FTP: >> no data) request. HEAD also ressembles HTTP-only, maybe rename to >> 'fetch_no_body' or something like that? Suggestions? >> * `ecore_con_url_received_bytes_get(con): int` **(issue: progress is >> double! change to uint64_t/off_t?)** > > if we have this... why not just store all of the progress info in the url > object and have the progress event have no actual data in it - just the > object, > and you get the progress property info from the url object? then we dont have > both the url pregress event struct AND the data on the object as well. just > have it in one place. :) do we nee a progress event at all? we will offer "read" and "write" (for POST) events inherited from Efl.Loop_Fd (what is ecore_main_fd_handler_add), so the user will call read() or write() from the Efl.Io interfaces. Thus why expose progress signal? With that, most UIs will update much more than they should since connections are pretty fast these days. It would be much more reasonable to keep an Animator around and keep it running after you did read()/write(), once the animator runs it will pause/remove itself. >> * `ecore_con_url_proxy_set(con, proxy)`, take user and password to >> avoid 3 functions? Maybe ask them to be url-encoded such as >> http://user:pass@domain/path and then use a single string? > > how about we do proxy objects as was beginning to be discussed for efl.net? > same proxy objects even so if its a socks proxy it works for both... http of > course is just an http proxy.... :) could be as well, Qt does proxy objects. The nice thing is that these objects (agents) may even ask you for some input, like when authentication is needed. >> * `ecore_con_url_proxy_username_set(con, username)` >> * `ecore_con_url_proxy_password_set(con, password)` >> * `ecore_con_url_url_set(con, url)` remove? > > make this the efl.net address? :) benefits of it being a string... :) inherit > from efl.net and subclass and extend where needed... ? good catch, but may be confusing to the user -- solvable with a documentation at the class. >> * `ecore_con_url_authentication_set(con, user, pass)` general >> authentication data (replaces ftp_upload() and httpauth_set()). >> * `ecore_con_url_upload_file(con, src_fname)` works for most >> protocols such http and ftp, replaces ecore_con_url_ftp_upload(). > > ok. filename. what about maaking cedric happy here and supporting an > eina_file? :) or really a binbuf wrapped around the data in an eina_file thats > mmaped will ... do the job... :) but this api can use sendfile() more > efficiently tho... :) see my other thread about Efl.Io interfaces. If we add a Reader and a Writer interface, we can offer Efl.Io.Copier class that will handle it nicely and we can remove these complexities. >> * `ecore_con_url_upload_data(con, cb)` to upload data created by a >> given function, allows streaming and pipe from other sources, not just >> files. > > hmm no cb... in eo api. some other way :) binbuf! :) binbufs can be wrapped > around mmaped mem data already :) any data in memory. mmaped files or > whatever. > but shouldnt this just be the send() method inherited from efl.net ? > > well more string verb-last naming above.. but ok. 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. Or the user manually hooks to Efl.Net.Http.Client "write" (from Efl.Loop_Fd) and then calls "write()" (from Efl.Io.Writer). -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ 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
