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

[Havoc Pennington]

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:
http://dev.eclipse.org/naming.html

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.

Havoc