Updated Perl API for DBus

[Daniel P. Berrange]

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");
    $remote_object->do_stuff($foo);
    
    ..do some more stuff...
  }

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

  &some_api(123);
  &some_api(123.0);
  &some_api("123");
  
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");
    $remote_object->do_stuff(dint32($foo));
  }

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.

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