On Sun, 17 Oct 2010 08:25:05 -0200 Raphael Kubo da Costa <k...@profusion.mobi>
said:

> At Sun, 17 Oct 2010 13:46:26 +0900,
> Carsten Haitzler (The Rasterman) wrote:
> > 
> > ugh. requiring curl outside of ecore_con to pass the httpost thing
> > in and out is wrong (tm). this needs to be wrapped. an ecore_con
> > data struct needed. this bit of the api is unusable as it stands
> > (imho) due to this. very good point.  this needs to be fixed.
> 
> Aside from the CURLFORM_COPY*/CURLFORM_PTR* siblings, are we thinking
> of a struct and code to keep a 1-to-1 parity with all those options in
> [1]?

hmm no - we shouldnt just copy/mimic it - what if curl changes its content.
well by mimic u mean make a struct that maps byte for byte as the curl one does
so we can make this work vs invent our own struct with the same "concepts" and
"content" and do the "translation" inside ecore_con from one to the other. i'd
always go for the 2nd option here.

> > ecore_con_url_time() also doesn't make me happy with time_t - i'd
> > rather double for time (as with other bits of ecore).
> 
> CURLOPT_TIMEVAL actually expects a long. We could store a double in
> Ecore_Con_Url, as long as you don't mind the cast when we pass the
> value to libcurl.

i dont mind. i just would prefer the api to have as much consistency with efl
ANd flexibility as we can - double means we get nice sub-second precision....
at the api level. if the protocol handles it or not is another matter
entirely :)

> > ecore_con_url_http_post_send(0 absolutely needs fixing to somehow
> > provide this via ecore_con wrapped stuff. ecore_con doesnt expose
> > curl as such and whatever implementation of http exists inside is
> > hidden, so it shouldnt expose the curl data struct requirement here.
> 
> Hmm, if we come to think of it, ecore_con_url's API is actually
> heavily curl-dependent in its design, even if it does not expose curl
> directly to its users.
> 
> [1] http://curl.haxx.se/libcurl/c/curl_formadd.html

sure - but it doesnt expose it - thats the point. if you replaced curl with...
libsoup or whatever.. you could do it as long as you dont make it DEPENDANT on
curl entirely. sure it may require more work as translating to a very different
internal http handling lib may be hard - but it can be done. with things like
the above, we can't really feasibly do it as we are not providing the struct
and api at all - we are directly exposing curl.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ras...@rasterman.com


------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to