Uploader.close() fails if in Loading state

[James Henstridge]

When writing a test using Uploader, I thought I'd make use of the ability to send data straight away, and then just wait for the state change. Something like:

    uploader = folder.createFile(...);
    uploader->write(...);
    uploader->close();
    // wait for statusChanged to Finished

However, this dropped me to the Error state with the message:

    Uploader::close(): cannot finalize while Uploader is not in the Ready state

The preferred behaviour would be for the uploader to queue the close and send it after the buffered data has been sent.

To be honest, I wonder if we'd be better off not distinguishing between Loading and Ready states on the Uploader. Cancellation in the Loading state could be handled by firing off the CancelUpload D-Bus call once the initial D-Bus call completes.

[Michi Henning (michihenning)]

The difficulty I see is that the underlying socket isn't connected until we get the reply from the provider and we can set the socket fd.

I don't think it is possible to write to a QIODevice before it enters the valid state. The doc says:

"Before accessing the device, open() must be called to set the correct OpenMode (such as ReadOnly or ReadWrite)."

We don't call open(), but call setSocketDescriptor() instead (which is the moral equivalent of open()).

Unless I'm misreading the doc, any writes to the socket will fail until after it is connected, so we'd have to buffer up all the data that was written, as well as queuing the close() call.

It seems it would be rather complex to provide this functionality. It's also problematic to make it symmetric with downloads. There, I can't call close() either before the socket is ready (for obvious reasons).

I have a sneaking suspicion that doing this may be a bit too clever? As is, the rules are simple:

for both download and upload, wait until the socket is ready before you do anything else with it.