Announcing Wasabi - Unifying Desktop Search - feedback needed
Mikkel Kamstrup Erlandsen
mikkel.kamstrup at gmail.com
Fri Feb 9 18:39:32 EET 2007
2007/2/8, Kevin Krammer <kevin.krammer at gmx.at>:
> On Thursday 08 February 2007 22:35, Mikkel Kamstrup Erlandsen wrote:
> > Yes, that was the plan, it is a small thing to define them though.
> > I think we should only define the interface name and dbus had a magic
> > method GetObjectForInterface("org.freedesktop.blah"), but as far as I
> > this is not possible...
> An interface can be implemented multiple times.
> What would you expect such a call to return if you pass the interface
> org.freedesktop.DBus.Introspectable? (likely implemented by almost all
> on all connections)
Well, mostly it was just wishful thinking. If there where such a method you
would only use it if you in fact did care what object you got. The contract
of the method is just that you get an object implementing that interface. If
you need an object implementing Introspectable then it's you lucky day,
there's plenty :-) Normally you'd only request interfaces that has more
meaning implied than Introspectable, such as fx. the wasabi one which has an
As it is a bit besides the point how to obtain dbus objects (it's not gonna
change anyway), I guess there is no other way than the "standard" - define
interface and path (and perhaps connection) - which is fine by me anyway.
However, consider there would be a specified Wasabi D-Bus name, e.g.
> org.freedesktop.wasabi then the bus could start a service known to
> this name (see D-Bus activation)
> This is why I thought that the specification really should specify such a
> > This leads me to a question I've been thinking about... Why is it not
> > custom to version your dbus interfaces? XML namespaces (typically) does
> > that for example. I was wondering whether to use
> > org.freedesktop.wasabi.search.1 for instance, not that I expect the api
> > change. But if we ever add api we could define a .2 or something like
> > that...
> D-Bus interfaces is a bit like dlopen. If the method isn't present, you'll
> an respective error (assuming the service implemenation handles this
> And as you said, it is quite likely that if the interface would have to be
> extended, it might even make sense to specifiy a whole new interface and
> the old one for backwards compatability.
Once we settle on an interface it's not gonna change. Any api
additions/changes will go under another name. I thought about a naming
scheme like the following, but I sense that it's pretty non-standard:
I don't expect that we have to update the interfaces any time soon though.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg