<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, May 3, 2015 at 12:44 AM, David Faure <span dir="ltr"><<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday 08 January 2015 10:45:13 Mark Gaiser wrote:<br>
<br>
(wow, time flies)<br>
<span><br>
> The issue i see here is different processes. KIO::listDir is a process,<br>
> KDirListerCache lives in the client process.<br>
<br>
</span>I guess you didn't mean this litterally, because in that case it's wrong, both<br>
happen in the client process.<br>
<span><br>
> You want to do sorting in both processes.<br>
> 1. When the client initially asks a listing you want to do the sorting as<br>
> quick as possible to send back as little data as possible. So sorting on<br>
> the SlaveBase side. As long as not all data is known in the KDirListerCache<br>
> sorting would have to be done on the SlaveBase side. That would be the case<br>
> to change sort order _while_ data is dripping in.<br>
> 2. When all data is fetched you don't want to go over a socket to request a<br>
> different sorting method so then you would need to have the same sorting<br>
> operations on the KIO client side with data fed from KDirListerCache.<br>
<br>
</span>Obviously more complex than the current solution, but OK, let's see where that<br>
leads us.<br>
<span><br>
> I do think that KIO would need a new class for this that can handle a set<br>
> of predefined sorting and filtering operations if this entire "slave side<br>
> sorting" is to be considered for KIO.<br>
><br>
</span><span>> Just to be clear, when i said "slave side sorting" i meant sorting in - for<br>
> instance - SlaveBase. Not in the actual slave plugins.<br>
> Where exactly, i don't know, but certainly before data is being send back<br>
> to the application that requested a KIO::listDir.<br>
> Sorry if i confused you here.<br>
<br>
</span>Well, this requires the actual kioslave to first give all items to SlaveBase,<br>
doesn't it? Otherwise it can't sort them. So instead of incremental listing,<br>
this would wait until everything is available and then send everything; not<br>
sure it would appear faster to the user.<br>
(this depends on whether the time is spent doing the actually listing and<br>
creating of UDSEntries, or if more time is spent sending the stuff over the<br>
socket --- but you optimized that :-)<br>
<span><br>
> The advantage i see with doing this is allowing data to be visible for the<br>
> user as soon as data is available which will give the user a smoother and<br>
> faster experience.<br>
<br>
</span>Interesting you should say that, I think the suggested approach actually goes<br>
into the opposite direction from this goal.<br>
You need for all udsentries to exist before sorting, so it might take longer<br>
for the first items to appear, compared to the current solution, where a first<br>
set of items get sent over as soon as they are available, and then the other<br>
batch comes in and the two get sorted together.<br>
Which can make items move down, so I'm not saying it's ideal, but it<br>
technically does reach the above goal better :)<br>
<span><br>
> It allows for a mechanism of "show me the first 100<br>
> items of this massive folder in this particular sort order". Something that<br>
> isn't fully possible right now since the client would have to wait till all<br>
> data has arrived over the socket, then sort it, then present it. All data<br>
> would still have to be fetched on the slave side, but only X number of<br>
> entries would have to be send to the client allowing it to immediately<br>
> present the data. The rest of the data can then be fetched on a "need to<br>
> know" basis. Eg. when scrolling down for the next batch of 100 items. By<br>
> that time the slave would probably (depending on the folder size and sort<br>
> order) be done fetching all items and is ready to immediately send those<br>
> pre sorted batches to the client.<br>
<br>
</span>So the very first step is to find out how long it takes to create udsentries<br>
in the slave, and how long it takes to transfer them over the socket.<br>
If the first one is much bigger than the second one, then this idea would<br>
delay quite a lot the time until when the first items appear...<br>
<span><br>
> An added advantage is that the client could then just use KIO as streaming<br>
> API. Just like a youtube api or whatever streaming api. The client would<br>
> just have to implement "canFetchMode" and "fetchMode" if the Qt classes are<br>
> used. It should prevent the client from needing to implement complicated<br>
> threading and UI tricks to keep the UI smooth.<br>
<br>
</span>fetchMore is pull ("get me more now"), while entries get listed asynchronously<br>
and pushed via a signal, so I don't see how that would work, what would<br>
fetchMore really do?<br>
<div><div><br>
--<br>
David Faure, <a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>, <a href="http://www.davidfaure.fr" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE Frameworks 5<br>
<br>
</div></div></blockquote></div><br></div><div class="gmail_extra">Time flies indeed! I completely forgot about this thread.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Just going to respond here instead of inline.</div><div class="gmail_extra">I fully agree with your comments and actually start to doubt the usefulness (again) of having a SlaveBase side sorting approach.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I theory it sounds so neat to have a streaming api approach, but in practice the SlaveBase side would just have to wait till all items are fetched before it can sort. There would be a measurable time difference between:</div><div class="gmail_extra">1. SlaveBase fetching all items and sending a sorted batch to the client</div><div class="gmail_extra">2. and SlaveBase sending all items over the socket, clients waits till it has everything and sorts - aka, the current situation.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Point 1 will certainly be faster, but will it be worth the effort? For this - filesystems - it's probably just not worth it. The difference would be seconds at most (rough guess).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Lets take a step back to the actual goal that i try to achieve here. Perhaps there is another way that i haven't thought of yet?</div><div class="gmail_extra">There is basically just one goal:</div><div class="gmail_extra">1. Present data as fast as possible in the sort order provided by the user.</div><div class="gmail_extra"><br></div><div class="gmail_extra">How can we get there besides extreme optimizations on the SlaveBase + UDSEntry side (which i have done, more is on my todo list)?</div></div>