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