On Mon, 8 Aug 2016 17:25:27 -0300 Gustavo Sverzut Barbieri <[email protected]> said:
> Hi all, > > Now it's time to review Ecore_Con_Url towards a better API and then > provide that as a Eo object. The current ecore_con_url will stay the > same, but the new one can have some enhancements or simplifications if > needed. > > Before going into the review, the core question will be to have a > single core class with all methods even if they do not make sense (ie: > HTTP-specific) or multiple subclasses with protocol specific methods. > You can see methods split below. > > A second point is whether to allow reuse of Ecore_Con_URL handle to do > other requests. Reviewing the current code and cURL documentation I > found that we may enter inconsistent behavior, for example if a POST > is done then HEAD, it will need to reset some flags and we're not > doing that. To me it looks like create for a single operation and then > destroy, creating a new one if desired is the common pattern. > > Review: > > * 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. :) > * 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? > * 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. > * `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 ? > # Base > > 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? > * `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. :) > * `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.... :) > * `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... ? > Okay: > > * `ecore_con_url_new(url): con` > * `ecore_con_url_custom_new(url, http_method)` (works for HTTP, FTP, > IMAP, POP3, SMTP...) > * `ecore_con_url_free(con)` > * `ecore_con_url_fd_set(con, write_fd)` download to file (http/ftp > download, etc) > * `ecore_con_url_verbose_set(con, bool)` set cURL verbosity > * `ecore_con_url_data_set(con, void*)` -> `eo_key_data_set()` > * `ecore_con_url_data_get(con)` -> `eo_key_data_get()` > * `ecore_con_url_timeout_set(con, double)` > * `ecore_con_url_status_code_get(con): int` > * `ecore_con_url_response_headers_get(con): list` > * `ecore_con_url_ssl_verify_peer_set(con, bool)` > * `ecore_con_url_ssl_ca_set(con, file)` > > To be introduced: > > * `ecore_con_url_download_bytes_get(con): uint64` to complement > `ecore_con_url_received_bytes_get()` ok - but along with getting other proeprties like dwonload totoal, current, upload totoal, current. > * `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... :) > * `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. > # HTTP specific: > > * `ecore_con_url_post(con, data, len, content_type)` execute POST request > * `ecore_con_url_http_version_set(con, ver)` set http version to use > **(issue: add http2, etc)** > * `ecore_con_url_additional_header_add(con, key, val)` add Key: Value to > header > * `ecore_con_url_additional_headers_clear(con)` remove all headers > * `ecore_con_url_httpauth_set(con, user, pass, safe): bool` safe > blocks plain-text authentications such as HTTP Basic. **Should be > replaced with ecore_con_url_authentication_set() + > ecore_con_url_http_authentication_method_set()** > * `ecore_con_url_cookies_init(con)` > * `ecore_con_url_cookies_ignore_old_session_set(con, url, bool)` > * `ecore_con_url_cookies_clear(con)` > * `ecore_con_url_cookies_session_clear(con)` > * `ecore_con_url_cookies_file_add(con, file)` > * `ecore_con_url_cookies_jar_file_set(con, file)` > * `ecore_con_url_cookies_jar_write(con)` > > To be introduced: > * `ecore_con_url_http_authentication_method_set(con, method)` (basic, > digest, digest-ie, negotiate, ntlm, ntlm_wb, any, any safe, only) > * `ecore_con_url_http_allow_redirects_set(con, bool)` to set > CURLOPT_FOLLOWLOCATION and allow HTTP 3xx redirects. > > > # FTP specific: > > * `ecore_con_url_ftp_upload(con, src_fname, user, pass, upload_dir)` > execute ftp upload. Could be removed if `ecore_con_url_upload_file()` > is added. > * `ecore_con_url_ftp_use_epsv_set(con, epsv)`: just examples use > this, should be removed? > > > > For further reference, you can find an analysis of users of > ecore-con-url at > https://gist.github.com/barbieri/773440bfc747d902b34b33dbbe89bd1a > > -- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
