D5767: Postpone searches for half a human moment

[Dan Leinir Turthra Jensen]

leinir added a comment.


  In https://phabricator.kde.org/D5767#108088, @markg wrote:
  
  > I don't think adding a (rather massive) delay is the real fix here. It only masks the actual issue.
  >
  > What really happens (just opened the discover store for the first time ever) is that entries can flow in at any point, that might be an issue.
  >  Every batch can contain items for any position in the in the store.
  >
  > The query used to fetch the data should fetch it in order of appearance. That would fix the visual clutter issue you described.
  >
  > Secondly (but this is outside the scope of this report) it should probably implement a incremental loading logic. Right now it seems to fetch everything.
  
  
  I think you might be misunderstanding the base intention of postponing the search here... We do not have a giant data centre to host the kde store, where the search goes to, so we can't simply afford to swallow the many unneeded requests the existing delay causes. This is a part of a wider effort to ensure we only send requests to that server that we actually intend to make. You are correct, however, that this is in no way enough on its own, but we already caused a manual ddos on api.kde-look.org week before last, which caused a shutdown for about a day, and if we can avoid that in the future, we need to do so. This helps (only sends searches we want), but we do also need to batch and combine the searches (which needs to happen elsewhere, and as you say is outside the scope of this patch).

REPOSITORY
  R134 Discover Software Store

REVISION DETAIL
  https://phabricator.kde.org/D5767

To: leinir, apol
Cc: markg, plasma-devel, ZrenBot, spstarr, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, lukas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20170508/6cfbeed3/attachment-0001.html>