DCOP private Extension (k_dcop_private:)
martin.konold at erfrakon.de
Mon Aug 25 18:54:53 BST 2003
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
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
This boils down to a concept like the oo public, protected, private and friend
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:
This is supposed to be a synonym for k_dcop:
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.
class DCOPDemoIface : virtual public DCOPObject
some declarations for the public interface
some declarations for the private interface
Actually Alex new dcop idl compiler (rewritten in perl) could handle this
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.
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.
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 at erfrakon.de
More information about the kde-core-devel