Source Compatability and DCOP

[Don Sanders]

For KAddressBook DCOP was used as a temporary solution until a more 
permanent solution was implemented. In this case the DCOP interface 
was not public.

In the future I think it may make sense to use DCOP for private 
communication between a family of tightly coupled applications like 
kde-pim. In which case these DCOP interfaces will not be public.

I would like a standard way of marking such interfaces as being non 
public.

I won't limit my use of DCOP to only creating public APIs, that makes 
no more sense than forcing all C++ member variables and methods to be 
public. Please think about that and then it should be obvious it's 
useful to have non public DCOP methods.

For the record I haven't promised to kept compatibility with any 
existing DCOP apis. I don't regard them as a subset of the frozen KDE 
libs. 

On the other hand I have no intention of breaking compatibility, I 
would only endorse it if there was a good reason.

Don.

On Friday 09 August 2002 03:47, Waldo Bastian wrote:
> On Wednesday 07 August 2002 09:36 pm, Don Sanders wrote:
> > IIRC the KAddressBook DCOP interface was commented as being for
> > the use of KPilot.
>
> If you type "dcop kaddressbook" it doesn't say "don't use these
> funcions" in large red bold blinking letters.
>
> Cheers,
> Waldo