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
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
