test suite failure - more detail ...

[Havoc Pennington]

On Tue, 2004-04-20 at 04:49, Olivier Andrieu wrote:
> Hmm, actually the proxy should have 3 states : 
>  - initial (we don't wether the service exists, no signals, method
>    invocation may fail with a ServiceDoesNotExist error),
>  - disconnected (we know the service doesn't exists, no signals nor
>    methods),
>  - connected (we know the service exists, process signals and methods)
> 
> That would also works nicely with activation: when creating a proxy
> with activation, we asynchronously send the "ActivateService" message
> and upon reception of the reply, we switch the proxy's state.

We might want to wait until we have more real-world usage and know the
use cases. It seems likely to be a good idea but I find it hard to know
about the details while we're operating in something of a vacuum.

Another possible API is:
 DBusServiceState dbus_gproxy_get_service_state (DBusGProxy*)
 typedef enum { DBUS_SERVICE_STATE_OWNED,
DBUS_SERVICE_STATE_NONEXISTENT, DBUS_SERVICE_STATE_UNKNOWN }
DBusServiceState;

with signal "(* state_changed) (DBusGProxy*, DBusServiceState old_state,
DBusServiceState new_state);"

But are apps testing for whether the proxy is ready to emit signals, or
are they testing for whether the service exists. How does this relate to
dbus_bus_service_exists() for example?

Why would you check for proxy readiness, to avoid race conditions? If so
how would you block until the proxy is ready, or how would you sync with
another thread or process?

Anyway, a few questions in my mind about the most useful way to expose
this.

Havoc