Questions on the new KIO::FileJob API

[nf2]

Thiago Macieira wrote:
> nf2 wrote:
>   
>> 1) - Creating Files: Apparently FileJob in kio_file doesn't allow
>> creating files. As there is no QIODevice::Create flag in the
>> QIODevice::OpenMode enum, it should probably create the file on
>> QIODevice::WriteOnly. Although i believe it would be good to have a
>> QIODevice::Create flag which prevents overwriting by mistake. Please
>> have a look at the GIO GFile API also...
>>     
>
> It was probably not conceived for creating files. If you're going to 
> create one, use KIO::put.
>   

Really?

>   
>> 2) - Reading Files: From reading the code in kio_file i'm not sure
>> whether data() is supposed to emit all the requested data in a single
>> callback, all the requested data in multiple callbacks *), or only as
>> much as it can get (>1 bytes) **). The latter would allow to have a
>> POSIX style streaming API, which has been missing in KIO anyway. This
>> would also work the other way round - when writing - as the written()
>> callback has a byte count.
>>
>> *) this is what the current - kio_file implementation suggests, but i
>> guess that's pretty dangerous, as the client might try to call seek()
>> before read() is finished.
>>     
>
> It emits as much as it can read, multiple times, until it has read the 
> amount of data requested. You shouldn't be calling seek() until you've 
> got the entire "mouthful" that you requested.
>   

Hmm - probably i wouldn't design it that way - i would stick to the 
behavior that is common elsewhere: one read() - one data() reply which 
can return less than requested. IMHO this would have two advantages:

1) On slow connections it might take quite long until you got the entire 
"mouthful". You can't change the file position during this span. A 
problem for multimedia apps?

2) API simplicity. You don't need to memorize on the client side how 
much you have requested (and sum up the byte-counts of multiple data() 
callbacks to find out whether read() is finished).

However, there seems to be a missing

if (bytes==0) break;

in kio_files read() loop.

Regards,
Norbert