<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>By batching i mean send a bunch of data to the IO slave.<br></div><div>I hoped KIO::BatchRenameJob would be a start for me as the name does imply batching, but doesn't seem to be doing just that. It's merely that you call it with a list of url's which then sequentially get processed inside KIO::BatchRenameJob. What happens there (as far as i can tell from the code) is after each successful rename a new rename gets fired till all the url's have been handled.</div><div><br></div><div>KIO::SimpleJob is for just one url, that doesn't seem to be an option for my usecase*. </div><div><br></div><div>SimpleJobPrivate is where the KIO magic really happens, but it takes only one url (by design).<br></div><div>It does a lot of the heavy lifting and you'd probably not want to create a job on any lower level then that. The "m_slave" (KIO::Slave) member in SimpleJobPrivate the one i want to have access to, specifically for the send(...) command in m_slave. I want to send a CMD_MULTI_GET command and implement support for that in the thumbnail slave. But i don't quite see how to get there with the current KIO::SimpleJob or KIO::Job classes.</div><div><br></div><div>I can see a few options, but i don't know how realistic those would be.</div><div><br></div><div>1. Split SimpleJobPrivate into a:</div><div>  - SimpleDataJobPrivate : public JobPrivate</div><div>  - SimpleJobPrivate : public SimpleDataJobPrivate</div><div>SimpleDataJobPrivate would get no knowledge of the QUrl logic that the current SimpleJobPrivate has. It would contain all the connection and scheduler handling.<br></div><div>SimpleJobPrivate would be stripped down to inherit from SimpleDataJobPrivate and do what it does now. A public facing "KIO::SimpleDataJob" would be exposed to the public API side.<br></div><div>The downside is that the current JobPrivate class has quite a bit of file handling specifics that would be out of place for SimpleDataJobPrivate.</div><div>2. Expose a public send function in KIO::Job to send raw data to the underlying slave with a given command. KIO::SimpleJob can then make that function private, but making a new class that inherits from KIO::Job and sending some data then becomes much easier. Though i'm not quite sure how possible this is as i don't see where KIO::Job would get a KIO::Slave object...</div><div>3. Leave the jobs as-is and implement a queue mechanism in the thumbnail slave. So any subsequent calls to that slave while it's still processing an image will end up on a queue. It's possible and the least invasive way i can think of, but complicates the thumbnail slave side (possibly even SlaveBase) and is probably not as performant as sending a whole bunch of url's at once.</div><div><br></div><div>* = I'm trying to generate thumbnails as fast as possible. IO is not the bottleneck. I can thumbnail 4000 4k images in 120 seconds in sequential order which is reduced to ~22 seconds in parallel. It's not a perfect optimization but much faster. But for this to work in KIO the IOSlave needs to receive a bunch of urls to process.</div><div><br></div><div>Cheers,</div><div>Mark</div></div></div></div></div></div>