D-Bus Activation on Windows

[Ogden, Nick]

Thanks Simon, that's really helpful.

I'll grab the source and have a read for the rest. =)

Keep up the good work.

Regards,
Nick

-----Original Message-----
From: Simon McVittie [mailto:simon.mcvittie at collabora.co.uk]
Sent: 18 August 2011 11:07
To: Ogden, Nick
Cc: 'dbus at lists.freedesktop.org'
Subject: Re: D-Bus Activation on Windows

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



The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.