dah-dah-da-daaaaah! synchrotron!

[Aaron J. Seigo]

On Thursday, January 6, 2011, Frank Karlitschek wrote:
> Hmm. This parameter is not in the current spec and is not in attica or GHNS
> supported at the moment and makes it incompatible with clients like the
> MeeGo Installer an other servers like Maemo garage or others. It also

it doesn't make it incompatible with other clients. it does mean that we can't 
use Maemo Garage to distribute our own upstream scripts ... which doesn't 
matter since Maemo Garage, etc. will have their own install and management of 
packages.

> problematic if the user only wants to update a subset of the available
> updates 

this just gets a list of available updates or new entries since a given time; 
doesn't force any actual update.

> The current update system works via the version field where the
> client compares the current installed version with the available version
> and offers a possible upgrade to the users.

yes, and this is completely sensible in the general case (ignoring that it 
falls apart for odd versioning schemes, though it seems developers are 
generally smarter / more predictable than that :)

grabbing lists of possible updates since a certain date simply allows for a 
shorcut method: if we know when the last check was done, ask for any changes 
since then.

(btw, i have to fix a tz related issue with the current implementation of this 
... )

another possibly useful approach i'm looking into is being able to return all 
the version #s for a given set of addons.

the lack of a well-defined version # scheme is moderately troubling, but i'm 
trying hard to ignore that as a source of possible edge cases ;)

> It´s always possible to extend this functionality in the next version of
> the spec if you want but this should be discussed on the ocs list and we
> need a consensus between all the parties.
> 
> I think it is important that all the available clients and servers stay
> compatible.

i'm not even sure this will work out as desired; if it does end up being 
useful in practice, then i'll look into upstreaming it. right now i'm 
collecting requirements from different app teams and looking for commonly 
useful solutions. it's too early to think about adjusting OCS quite yet.

-- 
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/20110106/565f3473/attachment.sig