[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-active
Subject:    [bodega] [Bug 317192] Update system
From:       Aaron J. Seigo <aseigo () kde ! org>
Date:       2013-03-25 15:34:34
Message-ID: bug-317192-152164-V3yB5OtUYY () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=317192

--- Comment #8 from Aaron J. Seigo <aseigo@kde.org> ---
The server currently requires the client to query one item at a time. This is
horribly inefficient and will not scale. As you noted earlier:

"You can add an API call to query N assets in 1 call,"

Which is (part of) what needs to happen. Updates to a given asset also contain
the timestamp of the update; version numbers are harder to parse (without
requiring everyone to strictly follow a known set of formats).

We do need to rely on the client-side to keep track of what versions of what
are installed (something not all of the installers currently do) so that the
return values can be meaningfully compared ... 

So it might end up looking something like:

path: /checkUpdates
args: 
 * number seconds (time since last check; 0 for show all current version #s)
 * array number assetIds
return:
 * dict { number assetId, string version, number timestamp }

assets not updated could be omitted in the return.

we probably want to put a maximum limit on the # of assetIds to be queried at
once, e.g. 100.

that's also a relatively "shortest path to the goal" type of API and as such
may not be the best thing. 

it would be nice, for instance, for the server to be able to flag content as it
is updated as being of interest to a given user account since they had
downloaded it in the past. this could end up being much more efficient, but
would need to handle multiple-device situations without keeping an infinite
backlog of all things updated that the user account ever downloaded for all
time. If we required a device ID, that would be easier to accomplish, but
that's not something we can rely on.

Sooooo .. needs some thinking. Worst case is we implement the naive API and at
least optimize N queries to N/Max_Asset_Ids queries.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Active mailing list
Active@kde.org
https://mail.kde.org/mailman/listinfo/active
[prev in list] [next in list] [prev in thread] [next in thread]