D-Bus Activation on Windows

[Simon McVittie]

On Thu, 18 Aug 2011 at 09:31:23 +0100, Ogden, Nick wrote:
> 1.       Is D-Bus activation supported on the Windows platform? If so, how does one set this up?

The code looks as though it's meant to work, at least - I don't know how well
it's been tested, but I think KDE on Windows uses activation, so we'd have
hopefully heard if it was badly wrong. If it turns out not to work, please
report bugs in (freedesktop.org) Bugzilla.

We only have one active Windows developer (Ralf), so if you run into
problems, be prepared to spend some time debugging them.

> I have created the .service file, but I'm not sure where this needs to be placed.

somewhere/dbus-1/services - consult the source code to see what "somewhere"
means. If dbus-daemon.exe is in a bin/ directory, it's probably
share/dbus-1/services/ relative to the same place?

> I'm assuming that the XML interface description will also have to be available to the daemon somewhere, is this correct?

No, the dbus-daemon only needs to know what well-known bus name
("service name", e.g. com.g4s.usa.MyService) that the service will provide.
Object paths, interfaces, methods, signals and properties are an agreement
between the service and its clients; dbus-daemon doesn't care, it just passes
messages.

> 2.       In the event that a service provider crashes, is the following assumption of behaviour correct?
> 
> Any undelivered message will cause an error to be returned to the sender. Assuming the service is setup for D-Bus activation, the next message shall cause the daemon to reactivate the service. If D-Bus activation is not configured, errors shall continue to be reported upon message attempts until the service is restarted manually.

Almost.

* If a method call has been delivered to the service, but it hasn't answered
  by the time it crashed, dbus-daemon will synthesize a NoReply error
  on the service's behalf and send that to the caller

* If a method call is in dbus-daemon's outgoing queue to the service, I don't
  know what happens without looking it up; see the dbus-daemon source code for
  details (it's in the bus/ directory of dbus tarballs/git repository).
  This might well be a NoReply error too.

* If a method call is in dbus-daemon's incoming queue from the sender,
  when dbus-daemon gets round to processing it, it'll cause re-activation
  (or an error if activation fails, or a ServiceUnknown error if there's
  no .service file)

(However, if a service fails by deadlocking instead of by crashing, you'll
get timeouts (NoReply errors) forever. Some projects I've worked on have used
an alarm()-based "watchdog" to make sure they die from SIGALRM if they get
stuck for too long, but I don't think that's available on Windows.)

Regards,
    S