using dbus in the platform
hp at redhat.com
Tue Oct 9 11:19:07 PDT 2007
Simon McVittie wrote:
> In other cases, it's difficult or impossible to tell what's OK and what
> isn't unless you have access to appropriate libdbus internals. For
> instance, try_register_object_path.
> I'm not suggesting introducing "try" versions of *every* API function,
> but just the ones where it actually helps.
It sounds like we may agree on how to handle all or most of the specific
functions. Once we get down to concrete specific stuff there may not be
much debate here.
If you don't think we need to deal with path validation, etc. in
libdbus, then there is potentially not a ton of work to do - I think
almost all the "checks" in libdbus are simple verifications of arguments
being not-NULL or valid paths/interfaces/whatever. Though I do think it
would be fine to have the _checked variant API if several bindings would
find it handy.
> Neither am I suggesting any sort of blanket change to libdbus -
> introducing a _try_ version on a case-by-case basis, wherever the checks
> and the API contract are subtle enough that they're easy to get wrong
> or only libdbus can know whether you're complying with the API contract,
> makes much more sense.
> However, at the moment there are cases (like register_object_path) where
> it's very hard to tell whether you are actually complying with the API
I essentially agree with you, I think. The guideline I suggest is
whether a given "module" (say a plugin or a library) that is in the same
process as other modules, sharing the same connection, but not
maintained together with those other modules, can be sure it is sticking
to the API contract.
In the case of registering a path, I have no idea what other modules may
have registered, so right now I can't be sure.
In the case of passing in a valid path, I do have control over that just
by getting my own module correct.
More information about the dbus