dah-dah-da-daaaaah! synchrotron!

[Frank Karlitschek]

On 07.01.2011, at 01:47, Aaron J. Seigo wrote:

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


Introducing custom parameter kills OCS as a standard because this means that not all clients can talk to all servers.
This might not be a problem if some is using only plasma and your server but it breaks the idea of OCS.

And I don´t really understand why because it is absolutely no problem to work together with the other server and client developers and put it into the official spec.


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

Perhaps it´s not complete clear in the spec but there is in fact a system.
We discussed this with the MeeGo and Midgard guys during academy. A higher number in the version field means a newer number which is than offered to the user as an update.
The version field don´t has to be the real version string like "KDE 4.6 RC2 patch 17" it can a random number. It just has to be increased to push a new version to the users. This is how it work in the new MeeGo Installer for example.
Cou could just use the git revision number in the version field and your done. GHNS already handles this correctly.



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

Sure. :-)

I just want to suggest to don´t fork OCS. 
The changes should be in the spec when your system goes into production.


Like I said already I like your initiative a lot. This makes KDE more independent from distributions and allows as to push changes without distro packaging hell. ;-)



Cheers
Frank


> -- 
> 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
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel


--
Frank Karlitschek
karlitschek at kde.org