The server should offer an API that can be queried for all possible updates to installed components. The device should be able to retrieve all items that have been updated since installation which are installed on that device. Reproducible: Always
We already have such information, don't we? At least in Bodega I can figure out the updates... Why do you need further API for this?
*Sorry I meant Muon
1. How is muon related with the bodega? If I download some component from the bodega content system and the component gets outdated how will Muon get this information? 2. AFAIK muon is a set of package management utilities for Debian-based Linux distributions, so if my distribution isn't Debian-based, how do I solve this use case? Simple said how does Muon solve this use case?
Aleix: for software packages, mostly ... but for things like books, not really. I also would like to avoid querying the server for each installed package one at a time and instead have a bulk query service that will allows us to limit queries in the vast majority of cases to single calls. Does that make more sense? (if not, I'm happy to rethink this :)
@Giorgos Muon has backends. It has an apt backend and a bodega backend. http://www.proli.net/2013/02/19/muon-discover-new-version-new-features-new-look/ @Aaron well, it's understandable but also it shifts the responsibility to know what's installed to the server, which I don't love. You can add an API call to query N assets in 1 call, to do that.
I don't believe I proposed any specific mechanism anywhere so far in this BR. Until there is an API proposal, it is not possible to say where what responsibility will lie. I do agree that the server can not be expected to rationally know what things are installed on a given device at all times (too many ways to change the device manually, as just one issue) and the local device will know correctly which items need to query the bodega server (items installed via an online repository with built-in updating won't need this, for instance). Whatever the API ends up being, those issues do indeed need to be taken into account.
Agreed, what I mean is that the server is already providing this. It seems of a client library feature missing, IMHO.
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.