On Sun, 17 Oct 2010 07:51:14 -0200 Raphael Kubo da Costa <k...@profusion.mobi> said:
> At Sun, 17 Oct 2010 13:48:09 +0900, > Carsten Haitzler (The Rasterman) wrote: > > > > this is actually a good q... shouldnt it be unsigned long at any rate? (tho > > to be honest int is probably enough... but as u have to send in 1 go... 2gb > > might possibly be a limiting factor?) > > We have libcurl as a limiting factor anyway: values passed to > POSTFIELDSIZE will always be read as a long; additionally, a value of > -1 is used to tell libcurl we want it to calculate the size of our > POST fields with strlen(). > > If you really want to send huge files via POST, there's a > POSTFIELDSIZE_LARGE option that reads a curl_off_t instead of a long > (with the same -1 twist). We can always use that instead of > POSTFIELDSIZE, however this means we'd need to accept a curl_off_t (or > an off_t) as a parameter type, which in turn takes us to my other > email about using void* in ecore_con_http_post_send :) hmm i don't much like this -1 for that. size of 0 makes more sense... as such we shouldnt really care too much about curl's limits. on 64bit machines this limit will be... bigger... if we make it a long (or unsigned long). as such we need a way to give an error anyway - one error would be "too big". as such though this is pointing to this memory. we need to ACTUALLY fit this in accessible memory space. that means malloc it, put it on the stack or mmap it directly from disk. in this regard long is probably fine. any limit curl may have we should abstract. remember too this is a post of a file as a single http command. sending it all as a single 2gb or even bigger lump is most... well.. odd, peculiar or at least unreliable. anything sending that kind of volume of data likely would do it across many posts able to handle disconnects and re-sends etc. -- ------------- 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
