DCOP interface in kicker broke compatibility?

[Aaron J. Seigo]

On Wednesday 02 February 2005 03:09, Adriaan de Groot wrote:
> On Wednesday 02 February 2005 02:43, George Staikos wrote:
> >    It seems to me that the DCOP interface in kicker has changed, which
> > means that my existing scripts (and pre-programmed memory for typing dcop
>
> ..
>
> > kicker kicker restart".  Given that we publish these things as public
> > API, I think we need to be keeping compatibility on them.  Anyone know
> > more about this?
>
> Lauri noticed something similar recently -- has quit() moved as well? It

there never was a quit(). there was configure(), and it's back too.

> As George points out, a DCOP interface should be considered a published,
> public API for which compatibility is required to be preserved. (I remember
> KNotes' interface change, which even caused data loss in some cases with
> applications still expecting the old interface).

as this ends up putting the sort of restrictions usually associated with 
libraries only upon applications, i think this is a rather strict and not 
entirely useful position. i say this because suddenly application developers 
are required to consider interface compatability where they usually don't 
have to, which makes application development more laborious.

of course, we also want applications maintain settings compatibilities across 
versions, ergo kconfig_update scripts. and there are benefits to maintaining 
DCOP interfaces across versions, as has already been noted.

therefore i'd like to suggest we consider a few things for IPC in KDE4 (some 
of which Waldo has already noted):

 - a set of written, agreed upon guidelines, just as we have for library BC 
concerns on developer.kde.org. is it enough to keep the call, but change the 
functionality of the call, for instance?

 - examine if _all_ applications using DCOP need to fall under DCOP "Call 
Compatibility" (CC?), or if it's just apps that ship with the core desktop or 
are part of a larger group of cooperative applications.

 - the ability to mark/flag DCOP calls as not public. they may still be 
visible, but have no guarantees for being carried forwards, perhaps. or maybe 
public, stable calls need to be white-listed as such: "stable, compatibility 
guaranteed"

 - looking at defining sets of standard DCOP interfaces for various classes of 
applications. we have a few already, for instance for media and IM. but it 
seems a little silly to be talking about interface stability when the 
interfaces are a house of babel. if we want interface stability, that means 
we intend for them to be used, and if we intend for them to be used we should 
start treating them (and therefore designing them) in such a manner.

a lot of this seems to point towards moving away from ad-hoc "this looks like 
a cool call to expose" development of IPC interfaces, and towards putting a 
bit more thought into it.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050202/b3769b07/attachment.sig>