Semantics of o.fd.DBus.Properties

[Havoc Pennington]

Hi,

On Feb 8, 2008 9:07 AM, Matthew Johnson <dbus at matthew.ath.cx> wrote:
> I agree. I think that the official D-Bus spec should actually be what is
> conceptually allowed and supported by the majority of the bindings /
> implementations. Otherwise we're allowing people to reply to methods
> with a different signature to the one specified in the introspection,
> for example. Or not sending a reply/error at all. (clearly these are Bad
> and Wrong, but they are allowed by the low level spec...)

For these two examples, fwiw, I don't think you would write any code
differently if the spec talked about them.

I mean, it's clear that callers already expect that methods have a
reply, and that the reply has the expected signature. But, at the same
time, it's clear that callers should check these things. If no reply
arrives the caller should time out, and if the reply is mangled the
caller should treat it as if an error reply had been sent, most
likely.

So, if someone doesn't do these things properly, their app or binding
just isn't going to work. I wouldn't expect in practice that people
sit around writing apps and bindings that don't work (not on purpose
anyway).

To me then the issue isn't that the spec allows this sort of thing
(here "allows" means: "does not caution against shooting self in
foot"), but maybe more that the spec doesn't explain it; you might
have to shoot yourself in the foot to learn that you should not, if
you're writing a binding from scratch.

All that said, of course the spec is not a very complete document, and
elaborations/clarifications/improvements would be very welcome.

> Failing that we do at least need _a_ spec that binding writers can use
> to implement and API authors to limit themselves to. My cross-binding
> test suite is probably a good start for that.

Agreed. Doesn't the current spec have a "guidelines for bindings"
section already, although a short one? More could be added to that, or
a new section created, or a new auxiliary spec. Whatever is
convenient.

> I think you should certainly be able to do this. On the subject, while I
> know methods can always throw things which _aren't_ declared, can we
> please have a way to specify common exceptions thrown by methods too?
> (I'm thinking annotations, maybe)

I know there are a couple lengthy threads in the archives on this, we
should definitely post links to those before rehashing.

Havoc