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]? > 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. > 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 -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ------------------------------------------------------------------------------ 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
