On 08.01.2011, at 19:25, Aaron J. Seigo wrote: > On Saturday, January 8, 2011, Frank Karlitschek wrote: >> On 07.01.2011, at 19:39, Aaron J. Seigo wrote: >>> On Friday, January 7, 2011, Frank Karlitschek wrote: >>>> On 07.01.2011, at 01:47, Aaron J. Seigo wrote: >>>>> On Thursday, January 6, 2011, Frank Karlitschek wrote: >>>> Introducing custom parameter kills OCS as a standard because this means >>>> that not all clients can talk to all servers. >>> >>> which actually isn't relevant in this case. >> >> why? You suggest to extend an open standard with a custom parameter so that >> it only work with your server. This kills the standard. >> I think this can and should be avoided. > > please read what i've written again, in particular: > > * mass update checking is not actually covered in the spec (just per-item > update timestamps)
It´s not supported by a single call, that right. But it already works for the MeeGo Installer and GHNS with individual checks. And an additional call can be added without a problem if you think it makes sense. > * this is experimental, i don't know if it will work, so i am not interested > in trying to push it into a standard until we have some working experience > with it sure. :-) I agree completely. > * this is ok, because interop doesn't matter right now since we do, indeed, > control both the client and the server side of it. everything will continue > to > work absolutely fine with other implementations aside from this one specific > aspect Sure. I think we should check what happen if your client talks to a different server or if a different client talks to your server. Both should work without problems to the enduser. > if the point of the spec is to suck in every single feature anyone implements > ever it's going to become a really ugly specification full of half-baked (or > worse) ideas. the spec is already a bit unwieldy. once we have some > experience > with implementing this specific feature set on the client side, then we can > take it to the ocs list. That´s good. Please do > > -- > 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@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel -- Frank Karlitschek karlitsc...@kde.org _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
