using dbus in the platform

[Havoc Pennington]

Hi,

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
> contract.

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.

Havoc