[ANNOUNCE] D-Bus 1.0 RC 1 (0.93) released

[Kimmo Hämäläinen]

On Tue, 2006-09-19 at 17:49, ext Havoc Pennington wrote:
> Kimmo Hämäläinen wrote:
> > 
> > You can never be entirely sure that the arguments are valid, because you
> > don't necessarily have the same information as the library has. 
> 
> Give me an example where this is true.

I'm talking about a general case: validness can be time-dependent, and
the library can only detect this at the time the function is called.

> > In some
> > cases it could even happen that the arguments become invalid after you
> > have validated them but before you had the chance to call the function.
> 
> How can this happen? With threads?

It's probably dependant of the D-Bus implementation (for example, some
implementation could check the validation of a match using information
about existing services). If the API should be as stable as possible, we
should not ask for trouble by specifying the API thinking only about the
current implementation.

>  >> Having every function validate everything is both
> >> incredibly high-maintenance and cpu-intensive.
> > 
> > I'm not proposing more validation to be done by the library.
> 
> If the app can't validate, and the library shouldn't have more 
> validation, who is going to validate?

I meant that I'm not proposing additional validation to the existing
functions, because you were saying that it would slow down.

> > It's an issue to detect OOM, as I have said above. I think D-Bus API
> > should allow unconditional detection of OOM, as any sensible API does.
> 
> Again, if there is a function where detection of OOM is impossible, we 
> will fix it. In all cases I know of, the return_if_fail checks are 
> avoidable by the app developer, and other than those checks the return 
> value unconditionally means OOM.

I'm not saying that detecting OOM is impossible, I'm saying that the API
does not make it 100% reliable in the general case (especially if the
library implementation is changed). The library already knows when OOM
happens, we just would need to tell the user about it.

> If you like, we can make the return_if_fail checks return TRUE for 
> functions where FALSE means OOM.

The return code should only have one meaning. As I said it could mean
'error happened' and then the get_error() (or something) could be used
to ask for the type of the error.

> Keep in mind, I fully agree that we should add the name validation 
> routines so people can use untrusted interface/object-path names.

I think I cannot convince you about the other issue, so I'm giving up. I
had to try... :)

BR; Kimmo

> 
> Havoc
>