continued: Common-VFS proposal

Waldo Bastian bastian at
Wed Jan 26 20:52:41 EET 2005

On Wednesday 26 January 2005 19:48, nf2 wrote:
> In KIO you probably run crazy with two TranferJobs and (ring)buffering
> data inbetween receiving data() and answering dataReq() callbacks. You
> have to be really cautious that your buffer doesn't grow to much - in
> cases the destination is slower than the source. You will need all kind
> of magic with TransferJob::suspend()/resume() to get this right. 

Just use the Alternating Bitburger [tm] protocol from CopyJob. 

> And the
> performance will be terrible, because two slave processes and your
> main-loop are involved.

In a CLI environment you wouldn't need the overhead from your mainloop, you 
could block on the filedescriptor of your slave IPC directly.

> The frontend API sould always stay as convenient as KIO:: and
> KIO::NetAccess. But there are special cases where a synchronous
> streaming interface is very usful IMHO.

I don't think it makes sense to base your main architectural decision on the 
needs of some speculative special cases. It's straightforward to provide 
synchronous read/write style streaming access in a KIO::NetAccess kind of way 
if there was a need for it. We don't provide it in KDE because nobody asked 
for it so far.

bastian at   |   Free Novell Linux Desktop 9 Evaluation Download
bastian at  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 

More information about the xdg mailing list