Further bindings stuff

Daniel P. Berrange dan at berrange.com
Thu Apr 6 10:03:13 PDT 2006


On Thu, Apr 06, 2006 at 04:34:35PM +0100, Matthew Johnson wrote:
> On Thu, 6 Apr 2006, Daniel P. Berrange wrote:
> 
> >Errors:
> >
> >The list of error conditions you've defined covers all the general cases
> >I've got handling for in the Perl bindings, so it looks reasonable. If
> >anyone implements the org.freedesktop.DBus.Properties interface, then
> >I can recommend a couple more errors to be standardized:
> >
> > org.freedesktop.DBus.Properties.Error.AccessDenied
> >   - An attempt was made to write to a read-only property,
> >     or read a write-only property
> >
> > org.freedesktop.DBus.Properties.Error.UnknownProperty
> >   - There was no property with the requested name
> >
> > org.freedesktop.DBus.Properties.Error.PropertyFailed
> >   - The attempt to read or write the property was unsuccessful
> 
> Good points
> 
> >Features:
> >
> >I don't think it is particularly useful to define two explicit levels of
> >of feature support - if only because I don't think there is any practical
> >way to determine what the cut-over point should be.
> 
> I was thinking there should be a minimum set of features which people
> should provide to be considered an 'official' binding. A complete list
> is useful for people to check against.
> 
> >What would be useful, however, is to take your list of features and
> >write a test case (or two, or three) for each one. Then we can put
> >together a matrix with features on one axis, and bindings on the other
> >axis. So an app developer looking to see whether a particular binding
> >will do what they need can just check against the compatability
> >matrix.
> 
> This would be good as well.
> 
> >Testing:
> >
> >In general we should have tests for each feature in the matrix. Extra
> >tests also for all the various edge cases
> >
> >- Handling of empty arays
> >- Send & receive of each basic data type
> >- Send & receive of each compound data type
> >- Compound data types with really deep nesting
> >- Calls an unknown method
> >- Calls a method with incorrect arguments
> >- Two interfaces on same object with methods of same name
> >- Handling of methods called without specifying an interface
> >- Un-registration of methods from the bus.
> >- Registration of new object, with same path as a previously
> >  un-registered object.
> >- Calling of remote methods from within a signal handler
> >- Verify correct UTF-8 string handling - pick a string with has
> >  characters with high-bit set and make sure they are encoded
> >  in UTF-8 and not something bad like ISO-8859-1 (or whatever $LANG
> >  is set to)
> >
> Yup, although testing some of these in java is quite hard, it doesn't
> let you call an unknown method if the server and client use the same
> codebase...

Yeah, I was thinking we wouldn't neccessary test both ends of such
things at once, since most of the bindings do have preventative 
measures in place. Instead we'd just have a simple C client (or
a perl/python client with introspection disabled) which tests the
Java server's handling of unknown methods. Conversely we could
stub out a server to pretend to implement a particular interface,
but just throw an UnknownMethod exception to see how clients 
handle it.

Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060406/192755af/attachment.pgp


More information about the dbus mailing list