At Tue, 19 Oct 2010 08:26:37 +0900, Carsten Haitzler (The Rasterman) wrote: > > On Mon, 18 Oct 2010 14:29:24 -0200 Raphael Kubo da Costa <k...@profusion.mobi> > said: > > > 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? > > point: if curl has a limit implicitly placed by using signed long (on 32bit > systems this is 2gb - on 64bit systems it's too big to bother discussing :)). > but if OUR api should directly reflect such limits is another question. > > is it really valid/sensible to be sending 2gb post data in 1 go? remember that > this will need to be memcpy'd on a 32bit system into an internal buffer so it > can be spooled out - so you will already fail as simply there is not enough > memory space to even do this. for 64bit systems.. is it sensible to even be > sending 2gb posts? i have my doubts. as the webserver will need to accept such > massive posts. i don't see that being sensible at all. if your connection > drops > you have to re-send.. the 2gb blob. as such thats a MASSIVE waste. wouldn't > reality be that any such massive file uploads would always be split over many > posts of much smaller chunks? if that is the case... we could just use an int > and be done with it. you still can't even manage 2gb on a 32bit system - and > on > a 64bit box that will be the theoretical limit, but in practice any such > protocol "design" that requires you post entire complete 2gb (or bigger) blobs > of data is a broken protocol anyway?
Well, I might be wrong here because it's too late to be digging through libcurl's internals right now, but at first glance, it seems to do any required splitting of the content into various requests when it cannot be sent all at once. -- 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
