dah-dah-da-daaaaah! synchrotron!

[Aaron J. Seigo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110107/1a28402f/attachment.sig