Updated Perl API for DBus

Daniel P. Berrange dan at berrange.com
Thu Nov 25 13:48:33 PST 2004

On Wed, Nov 24, 2004 at 06:47:58PM +0200, Andy Wingo wrote:
> > The place where we divert from Python is with data typing. Since Perl
> > is a very loosely typed language, fields are added to messages as strings,
> > arrays or dictionaries.
> Although explicit, it ignores any hinting that might exist with
> SvIOKp/SvNOKp/SvPOKp. I've never hacked perl in C, so I don't know how
> indicative these macros are of underlying types. Or what "underlying
> type" really means in perl.

The problem I see with using Sv{I,N,P}OKp tests is that they are really
answering the wrong question - that of what Perl thinks the data is 
representing, rather what the remote method requires. I think its important
that the remote method invocations to be 100% predictable with packing the 
data into a message, so if you provide an API backed by a DBus remote method, 
no matter how you are called the results remain the same. For example, consider 
an API 

  sub some_api {
    my $foo = shift;
    ..do some stuff...
    my $remote_object = $server->get_object("/some/object");
    ..do some more stuff...

If we used the Sv{N,I,P}OKp hinting, there'd be different behaviour between
the following calls

Now while a mis-typed message would be eventually caught and error thrown
at the server, I feel it is better to try and take advantage of Perl type
coercion, so for example

  sub some_api {
    my $foo = shift;
    my $remote_object = $server->get_object("/some/object");

Then all three of the above examples invocations would produce the
same results. So while there is a little more typing to provide the
explicit type casts, I think its worth it, in order to have predictable
behaviour regardless of data format.

Another approach for providing explicit typing that Leon suggested to
me is to use a sprintf/pack style, eg

  $remote_object->do_stuff(dbus_pack("issd", "123, "Hello", "World", 99.9));
which would encode an int32, string, string, double, and would require less
typing that my current scheme of wrapping each arg in a function call.

> On a deeper level, one should be able to query the signature of an
> interface -- this would make things a bit more clear. Tricky. Given
> Havoc's successful implementation of type-closure in compound types, and
> the implicit encoding of type in data (messages), maybe he has a bright
> idea ;-)

That's an interesting idea - I'm guessing that'd require extra API
support in DBus bindings for each language. That may not be worth the
extra effort just to satisfy the few weakly typed languages like Perl.

|=-            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: 232 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/dbus/attachments/20041125/d58363a3/attachment.pgp

More information about the dbus mailing list