dah-dah-da-daaaaah! synchrotron!

[Frank Karlitschek]

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


--
Frank Karlitschek
karlitschek at kde.org