Questions on the new KIO::FileJob API
thiago at kde.org
Sat May 3 15:45:09 BST 2008
>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.
>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.
>**) I wonder if there could be a "timeout" parameter for read() and
>write(). GIO, for instance, seems to allow cancellation of
No, there shouldn't be one. Read and Write operations are assured and
should finish in reasonable time. They should not get stuck for a minute,
unless there's a network issue.
In such case, it should be handled just like other KIO operations (get(),
>3) - Open ReadWrite doesn't seem to be implemented in kio_file - and
>it's not possible in GIO either. I wonder if it should. Probably it
>would work on filesystems like smb, sftp,...
Let's wait for a use-case first.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel