dah-dah-da-daaaaah! synchrotron!

[Frank Karlitschek]

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. 


> 
>> 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.
> 
> it isn't a problem. i just don't want to waste anyone's time (including my 
> own) working through a standardization process for something which we don't 
> know how well it will work in practice.

Thats sad to hear. I´m a big fan of standard.


>>> 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
> 
> this is precisely the issue: it isn't well defined so it can be "4.6 RC2 patch 
> 17". amarok's got a cute little "version number parser" that assumes an 
> "x.y.z" style approach. this really ought to be specified in detail in the 
> spec so that systems can be reliably built around it.

Well. It is defined but not good documented. But this is easily fixable :-)


>> 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.
> 
> git uses commit hashes, not revision #s, so i'm not sure if this would work to 
> well in the case of git.

Yes. You are right. 




--
Frank Karlitschek
karlitschek at kde.org