On Mon, 18 Oct 2010, Raphael Kubo da Costa wrote:
> At Mon, 18 Oct 2010 18:43:59 +0200 (CEST), > Vincent Torri wrote: >> On Mon, 18 Oct 2010, Raphael Kubo da Costa wrote: >> >>> At Sun, 17 Oct 2010 22:49:16 +0900, >>> Carsten Haitzler (The Rasterman) wrote: >>>> >>>> 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. >>> >>> Sorry, I've kind of missed the point while reading your message ;) >>> >>> Are you saying we should use an unsigned long even though it will be >>> read as a long by curl, or that we shoulduse POSTFIELDSIZE_LARGE, or >>> that it's OK as it is? >> >> on Windows 64 bits, long is of size 32 bits and not 64 bits. What about >> using int64_t ? > > We could do that, however when libcurl reads the value we pass to it > that value will be cast to a long anyway, no? maybe the libcurl devs are not aware of that Windows sillyness. I'll ask them Vincent ------------------------------------------------------------------------------ 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
