On 4/26/2009 12:55 PM, Shawn Walker wrote:
> Petr Sobotka wrote:
>> Indeed it was caused by enormous size of binary (271MB), I forgot to get rid
>> of -g1 flag from compiler options.
>> I didn't expect such big file ...
>> Would be possible to change error message to say something more useful, like
>> can't publish +100MB file into repo?
> The error message can't be improved beacuse of a limitation of the
> server framework we're using, but the client could check the size before
> attempting upload.
> The problem is that on the server-side, the http framework we're using
> automatically rejects uploads greater than a specific size without
> giving the application a chance to return its own error message.
> As a result, you get a generic error message instead of one actually
> pointing out the real issue.
>> In my eyes this limit is not enough.
>> For example some game can have intro video, which is greater than 100MB ...
> I agree, *but* it isn't really practical to publish files this size over
> http. http is a lousy protocol for large file downloads as it is, and
> its even worse for uploads.
> The basic python libraries for http transport are fairly pathetic, and
> currently require that the entire file be read into memory for
> publishing. Long-term, when a better transport system is in place, I
> hope to make publishing for http occur in "chunks" so that you won't
> have this file size limit.
> Finally, As I've mentioned before, you can easily workaround this by
> using file-based publishing direct to a package repository instead:
> pkgsend -s file:///path/to/repository_directory ...
> (Afterwards, you must restart any depot servers pointing at the repository.)
Then what's a safe and modern solution that's better than HTTP and
chunking? FTP is out of the question except for mirroring raw unpacked
packages and SCTP is a far way off from being a realistic option.