On Friday, January 7, 2011, Frank Karlitschek wrote: > I´m also not sure why the current update system using the version field is > not usable.
consider 5 addons are installed. with a version check that means: * sending across a request for each of those 5 items * on the server, looking up 5 different pieces of information (this can not be easily compressed into a single db lookup, at least not one with performance benefits) * sending back the current version #s, causing a look up of the local version #s for all 5 items on the client and comparing them when one considers that the usual answer is going to be "there are no updates" this is a lot of work for no great purpose. one of the thing that drives me nuts with package manager updates (including on my n900) is how freaking slow it all is. so ... with timestamps: * when a new or changed item appears, we record when it happened on the server (needed anyways by the spec) * a client that knows the last time it checked asks for all things changed since the last time it checked * the server does a simple date-based lookup for changes and sends that list back including version #s; in the case of no updates, the process is short- circuited right here and speed ensues * the client side then compares those version #s this is more efficient when: * there are more installed addons (the more addons installed, the more efficiency is gained) * updates are infrequent relative to update checks (the less often updates happen, the more efficiency is gained) in the case of most applications with addons, the number of addons grows over time but the number of updates remain infrequent. this also follows nicely with the "created since" method to check for new things. having the client side check the created on dates of a list call with sortmode=new is clumsy, imho. where the "updated since" method will fail is when: * there are large numbers of updates in the content store; for application addons this is quite unlikely, while for an app store with 100s of 1000s of apps for a phone or whatever it might be the case that there are 100s of updated apps per day * update checks are infrequent, losing any gains in efficiency to backlogs of updates piling up my best educated guess is this: for KDE application addons, we can eaisly up with 100s of 1000s to millions of requests per day for addon updates that are going to happen at the pace of a few per month. for amarok, they have half a dozen or so scripts, they are checked at regular intervals and since it was put in place early last year there have been 0 script updates. which means that for amarok, that's checks for 4 scripts every time i start it up over the past year for ... nothing. just load on the server and my computer here. fortunately, amarok only does this when you open up the script manager dialog. i'd like to see this feasible as something on each boot (max once per day) or every week, whichever happens first. for manual checks, we'll probably want / need to fall back on a "here are the things i have installed, send me version #s for each". OCS doesn't cover that either, btw :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
