Thiago Macieira thiago at
Thu May 13 06:36:34 PDT 2010

Em Quinta-feira 13. Maio 2010, às 15.21.13, Lennart Poettering escreveu:
> The interface parameter is necessary simply because this is what most
> existing services currently implement. Example: in PA we have GetSinks()
> and GetSources(), both of which return their specific kind of object.
> systemd I have something similar (GetUnits() and GetJobs()), and CK too
> (GetSessions() and GetSeats()) and udisks has something similar too
> (EnumerateAdapters, EnumerateDevices, EnumeratePorts, ...). It's simply
> how things work: if you want access to an object you need to know its
> type in advance, because otherwise you have little use for it. (with the
> exception of pure introspection tools like d-feet, which are however
> only good for debugging)

I think your design is fine. You have methods that return the list of objects 
that do whatever your API defines them to be relevant for.

And yes, you need to implement that sort of logic in many places. So what?

I don't think that the D-Bus standard interfaces need to do your job for you 

> What would be bad design is if we don't have this interface parameter:
> because then you would get a list of objects where you don't know the
> types.

That would be an example of bad design: scanning objects to see if they have 
an interface. I'm not advocating that.

I'm advocating your current design: you add a method that returns a list that 
your method thinks is relevant.

Thiago Macieira - thiago (AT) - thiago (AT)
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the dbus mailing list