1. Motivation and Background

Our current DCOP implementation basically lets you decide which parts of your 
application are exposed to every other application via DCOP.

By using k_dcop: everything within the scope of this declaration is exposed to 
everyone.

2. Maintainance/Compatibility issue

By exposing the functionality via DCOP actually this interface becomes part of 
the API of the desktop and shall remain compatible and be maintained for 
rather long times. 

The situation is not as bad as with libraries but still an author cannot be 
sure if any 3rd party is relying on the DCOP interface.

The result of this is that it is often no good idea to offer unstable 
interfaces via DCOP.

On the other hand it is oftern very useful to expose unstable APIs in order to 
allow for DCOP based applications like Kontact. Having a rich DCOP interface 
also allows for easier unit testing and automatic regression testing.

3. Possible simple solution to the dilemma

Make exposing functionality via dcop possible while hiding it from normal dcop 
clients.

This boils down to a concept like the oo public, protected, private and friend 
declarations.

4. Possible _simple_ Implementation of the solution (maybe short term relieve)

After some discussion today at the Kolab meeting and consulting with Ian 
Geiser, Alex, Ingo and many others we saw that something should be available 
to be able to expose e.g. kmail functionality without haveing to fear that 
people not familar with the status of the API will use it.

The simple solution to the needs could be to add the following two new macros:

k_dcop_public:
	This is supposed to be a synonym for k_dcop:

k_dcop_private:
	This is is to tell the dcop idl compiler to _not_ publish the functions but 
still making them fully accessable if the caller happens to know them.
 
Example:

class DCOPDemoIface : virtual public DCOPObject
{
     K_DCOP

     k_dcop_public:
 
	some declarations for the public interface

     k_dcop_private:

	some declarations for the private interface
};

Actually Alex new dcop idl compiler (rewritten in perl) could handle this 
requirement easily.

4. How to introduce

I propose to consider to ask for some assistance by the build system so that 
developers wishing to use k_dcop_private: can use Alex new dcop idl compiler 
instead of the old yacc stuff. 

Somewhen in the future (probably after 3.2) we can phase out the old dcop idl 
compiler and fully switch to Alex's new implementation so there will be no 
permant need for keeping two dcop idl compilers.

5. Compatibility

I think the proposed simple solution is a rather save approach. Basically not 
too much bad things should happen. All current applications which wish not to 
make active use of the new feature are not affected.

Applications like kmail/kroupware and kontact who desperately are in need of 
this feature can risk to use the new dcop idl compiler and therefore prevent 
innocent users from using the private API while allowing others kdepim 
developers to closely coordinate.
 
No changes to the dcop protocol nor the dcop server are required.

Yours,
-- martin

Dipl.-Phys. Martin Konold
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold@erfrakon.de