Semantics of o.fd.DBus.Properties

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 07 Feb 2008 at 23:08:50 +0100, Thiago Macieira wrote:
> Simon McVittie wrote:
> >GLib sort of does (it will mangle that name to "-i-am-on-crack" or
> >something, creating ambiguity with e.g. "_IAmOnCrack"). Qt does.
> 
> QtDBus does not apply any transformations at all on any names. That means 
> that, for anyone using it to have D-Bus style names 
> (GetCamelCaseCapitalFirst), you have to write identifiers that stand out 
> from the rest of the API (which is generally 
> camelCaseLowerFirstWithoutGet).

I actually consider this to be a feature. D-Bus is most useful (to me,
anyway :-) when using a publically specified API with multiple
implementations, cross-platform, etc. etc., and in those circumstances
it becomes important to know what's your C/C++/... API, and what's your
D-Bus API.

Obviously, if your D-Bus API is an ad-hoc remapping of your native API,
then using a naming convention consistent with your native API is easy,
but on the other hand it's going to be strange for someone else who's
interoperating with you.

QtDBus's model is quite interesting to me in that it moves *all* the
D-Bus bits to a DBusAdaptor that has little or no native API. I'll have
to bear that sort of thing in mind when I'm designing interface-based
API for the next generation of dbus-glib or dbus-python.

> >In both GLib and Qt it can never fail, unless the setter in Qt is
> >allowed to throw exceptions.
> 
> Exceptions in Qt in general cause bad behaviour and application exit. It 
> would be a bad practice to throw from the method handler.

OK, so the setter isn't "allowed" to throw exceptions in the same way
that GLib code isn't "allowed" to call abort() :-)

(I was wondering whether QtDBus caught certain exceptions and used them
to produce D-Bus errors, like dbus-python does, but, apparently not.)

> So it never fails in the sense that a call to Set always returns a 
> method-reply message, never a method-error. The Qt property mechanism 
> doesn't allow for failing anyways, so extending that might be difficult.

Right, so any API author who cares about Qt interoperability can't mandate
that accessing some of their properties can fail with an error.

See my mail to Havoc for what I really meant by "synchronous". (I've had
my head buried in telepathy-glib (aka "prototyping the future of dbus-glib")
for 3 months, and was working with dbus-python before that, so I'm used to the
odd way the terms "synchronous" and "async" get used in dbus-glib and
dbus-python services...)

    Simon
-----BEGIN PGP SIGNATURE-----

iD8DBQFHrFu9WSc8zVUw7HYRAsEeAKCDyaX0QYM+Kujvm2EI/Afw98TWGwCeNzoO
WRvkqGmVJjBGHnZLjfFDV94=
=D1RP
-----END PGP SIGNATURE-----