KIO slave using copy() - problem with canResume()

[Dr. Juergen Pfennig]

On Monday 08 March 2004 13:50, Stephan Kulow wrote:
> > .. but I am only 95% happy with it ..
>
> Are that the same 95% with the inlining compiler? :)

Hi Stephan,
thanks for the joke - the GNU compiler is not so aggressive as the M$ one. 
Decorating lots of methods with some KDE_NO_INLINE would cause another level 
of confusion - so here I have nothing to complain. My 5% are kio related. The 
slaves should call canResume() to give the user a hook (some slaves imply 
resume without asking - but I don't like that). But canResume() only works if 
the kio job has two ends that are different kio slaves.

> > if I find .part file locally. Unfortunately this doesn't work.
> > canResume() tries to send metadata from the calling end of the data-pump
> > kio_slave to other side of the data pump. In other words: while a copy
> > job executes inside copy() the KIO::slavebase members mOutgoingMetaData
> > and mIncomingMetaData should be equal, so that if you send meta data (to
> > yourself) you will able to receive it. This would make canResume() work
> > with copy.
...
>
> I for one can't even follow you here. What exactly is wrong? You only list
> what should be.

The 2-end problem: slavebase assumes (here) that a job has two ends which are 
both kio slaves (e.g. processes). Then meta-data will be sent from one 
process to the other. This makes no sense if a copy() job runs, slavebase 
even takes the konqueror instance that started the kio_slave (and that is now 
executing copy()) as the other end. If a slave running copy() dares to call 
canResume() or any other function that sends meta-data, the data ends up in 
Konqueror, which here is the wrong destination.

Conclusion: the kio job implementation partially supports copy() - exactly so 
that kio_file is happy, but the current implementation needs a bit of work to 
handle more general cases. kio_file just works because it does not call 
canResume()  and/or doesn't send metadata.

Yours Jürgen