https://bugs.kde.org/show_bug.cgi?id=317192
--- Comment #8 from Aaron J. Seigo <[email protected]> --- 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 [email protected] https://mail.kde.org/mailman/listinfo/active
