dah-dah-da-daaaaah! synchrotron!

[Marco Martin]

On Friday 07 January 2011, Frank Karlitschek wrote:
> On 07.01.2011, at 12:59, Artur de Souza wrote:
> > Hey Frank!
> > 
> > Quoting Frank Karlitschek <karlitschek at kde.org>:
> >> 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.
> > 
> > Even if it's an optional parameter? I mean, if the client understands a
> > superset of arguments of the OCS standard it shouldn't be a problem to
> > talk to any other OCS server right?
> > 
> > I understand your point for *required* parameters, but if this is an
> > *optional* one, it should work for everybody, doesn't it?
> > 
> > Cheers! :)
> > 
> > 
> > Artur
> 
> Well,
> 
> the question is what happens if a client send an "optional" parameter and
> the server doesn´t understand it. I think in this case all servers beside
> Aarons will ignore the parameter and return the wrong result set. The
> client has the impression that there are updates available for all
> installed plasmoids every time it checks. So this breaks compatibility.
> 
> I´m also not sure why the current update system using the version field is
> not usable.
> 
> It would be really cool to stay compatible at least inside KDE ;-)
> 
I think what's missing is a clear path to go from an experimental addition to 
something integrated in the spec (with the due testing before someting 
potentially bad is added to it)

I think it would be good to have some explicit way to mark exprimental things 
to allow them to be tried in te real world before ending up in the spec, maybe 
even just un the naming scheme, like a function called X-fetchUpdates

Cheers,
Marco Martin