o(ther)l/log

I released today v0.3 of S3 Browser (binary and source). It has some minor usability fixes (added drag-n-drop support in the objects view, double-click actions, and other small fixes). But the most important feature is that file upload and download no longer use local memory, the data is just streamed between S3 and the filesystem.

Implementing it for file download was a piece of cake, as NSURLDownload actually does almost everything for free. You just have to give the destination for the downloaded file - et voilà.

File upload was another story: when using NSMutableURLRequest to prepare a connection you can use setHTTPBodyStream instead of setHTTPBody to send the payload.
But... using a stream means that you usually don't know the content length upfront, so Foundation will send the message as chunked, without a Content-Length header (they are mutually exclusive).

And S3 does not support file upload using chunked-encoding (something I can understand). The conclusion is that you can't use a stream-based API at NSURLRequest-level to send your data if you don't want chunked transfers. That makes sense: you would need a new API, something like setHTTPBodyStream:forLength to precise what you're going to send.

So I ended implementing my own naive HTTP PUT client on top of NSInputStream/NSOutputStream and CFHTTPMessage, which works fine but does not get all the 'free' functionality available in the Foundation URL Loading system. For instance, if a web proxy is configured in system preferences, I fallback to my previous in-memory / NSURLRequest implementation.

The plan for the next version ? improving bucket content management, first to be able to deal with very large buckets, and also to see what can be implemented to take advantage of the new "hierarchical listing of keys" feature.