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. Cheers, Waldo -- bastian kde org | Free Novell Linux Desktop 9 Evaluation Download bastian suse com | http://www.novell.com/products/desktop/eval.html
Attachment:
pgp4GJnNUlaPs.pgp
Description: PGP signature