Short lived, or "private", objects on the bus

[Havoc Pennington]

Hi,

Mikkel Kamstrup Erlandsen wrote:
> Thanks. This is what we will do. I take it the way to do it is the way 
> Ross described by listening for NameOwnerChanged signals (at least it 
> works for me here).

Right, NameOwnerChanged is what you want.

> Allow me to sneak a related question into this thread... We need to 
> scale pretty good with regards to spawning searches. Fx ~50 searches 
> within one second could happen - will dbus be a bottle neck here if we 
> choose to make Search objects real dbus objects (because we need to 
> register each one on the bus)?
> 
> I assume that spawning a new object takes a round trip to the bus atleast...

Nope, object paths are kept in-process inside your app, the bus does not 
keep track of them.

The only single functions you can call in libdbus that do a round trip 
are the functions in dbus-bus.h that wrap a remote method call, and the 
DBusConnection methods with _block() in the name. Otherwise, a round 
trip will be something you can see in your code since you'll send a 
request, then later explicitly block for reply. The higher-level 
bindings sometimes make it easier to inadvertently add round trips, though.

The only round trip you are requiring here is that if a search result is 
an object, the app has to do:
  CreateSearch -> search daemon
  get back search object <- search daemon
  invoke method on search object -> search daemon

If you want to avoid that round trip, you would need the app to create 
the search object path, instead of having the search daemon do it. For 
example you could specify that the app will randomly generate a short 
string mkstmp()-style and send it to the search daemon, and the search 
daemon will create an object path with that name (or throw an error if 
the name exists already).

Xlib does pretty much exactly this; the X server allocates blocks of 
resource IDs to connected clients, then the clients use those blocks to 
assign their own IDs to resources they create.

This is probably overoptimization in your case, but it is a useful 
strategy to know.

Havoc