On Thu, 11 Aug 2016 10:09:27 -0300 Gustavo Sverzut Barbieri <[email protected]> said:
> 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. ok. going ot have to deal with io.reader over there in that mail thread. but we agree that efl/net/url should "inherit" the elf.net (socket/core/whatever) interface and re-use it as much as possible with extensions. cool. thats an important point. > >> * 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. aaah errr. ok. but i get it. > 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? i'm on the fence. reality is the PROTOCOL defines error codes. if there's just a set of enums mapped to ints to look it up... i'm fine with that. saves having to remember the protocol error codes yourself. :) a protocol specific interface can ensure it exposes the error code as a specific enum type only for type safety tho and this i think is good for bindings to other languages especially c ++. > >> * 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. yeah... it just looks... odd. :) anyway. > >> * `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. 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! > >> 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 i know. i kind of think it should... > 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. correct. which is why... i think a connect method here would be a good idea. it would make this far more useful. everything until connect is setting up state. you can add a resolve() too to explicitly do the resolve step on its own then too and then call connect() based on what resolve says. connect() is resolve + connect() (properly ordered based on resolve result - if resolve succeeds of course) > 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? or just use an explicit connect() :) far less complex and pretty obvious. :) > >> * `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? well no. as we can just ue the data/read/write events to GET progress at that time. > 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. actually ui is already fine with this. it wont re-render until the next frame anyway. we explicitly refuse to render unless the wakeup was due to an animator tick. so setting a progress widget value actually just sets the value, emits a signal to the ui and flags things as changed.... even if we get 100000 events a second it will only re-render at 60hz (or whatever refresh is). now do we want a progress event because we want efl/net to throttle such progress to a maximum # of events per second so to speak? maybe - it might be nice to have an ability to throttle here to something sensible so we dont force ui to have to get more and more aggressive at filtering out such noise too. > >> * `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. i prefer this way of doing this. :) > >> * `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. hmm well to my mind this is MORE obvious and less confusing. why do i have to learn/remember different methods to set the target for this network op... when there is one already? i have already been explicit with the class/type as to what kind of network op it is (http, tcp, udp socket etc.) and now i'm just providing the address info - a string. people are incredibly used to this idea of it being a string. browser have exposed the url as a STRING for ... a long time. :) it's the address bar. location string. it's kind of a generic concept. > >> * `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. i'll get to that separately. > >> * `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. 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. :) > 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 > -- ------------- 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
