DBUS introspection (Was: DCOP interface in kicker broke compatibility?)

Havoc Pennington hp at redhat.com
Wed Feb 2 08:27:26 PST 2005

On Wed, 2005-02-02 at 10:12 +0100, Waldo Bastian wrote:
> On Wednesday 02 February 2005 09:23, Scott Wheeler wrote:
> > On Wednesday 02 February 2005 3:56, Thiago Macieira wrote:
> > > As ugly as it looks, I think this is the right thing to do. We should
> > > break compatibility as little as possible -- not at all if possible.
> > >
> > > Mark the methods with // KDE4: remove
> >
> > What would be nice would be if there was a flag for the method that would
> > prevent it from showing up in the list of DCOP methods, but still be
> > possible to call.  Or at least some way of marking parts of the DCOP API as
> > deprecated...though I suppose it's a bit late for such.
> Something to keep in mind for the DBUS introspection format.

This is kind of related to the discussion we were having earlier about
public vs. private interfaces and some way to mark them... though it is
a different problem, not sure the solutions are the same. But we should
probably think about them similarly.

Eclipse takes a pretty simple approach on the private API thing, which
is that within each package there can be a namespace called "internal"
and those things are internal to the package:

so e.g. org.kde.internal.* is usable only by KDE itself.

That doesn't work for deprecated since you can't rename something to
deprecate... so deprecation is maybe a flag instead. We could make
internal/private a flag also, if we introduce a flags-type concept.


More information about the dbus mailing list