Method-chaining and Simple-types as objects

[John (J5) Palmieri]

On Wed, 2005-05-18 at 14:25 -0400, Daniel B. Faken wrote:
> Hello all,
> 
>   For what its worth, here is a DBus interface design to support sending 
> messages to Integers, Floats, etc. and to combine method calls that would 
> normally be sent individually.
>   I'm interested in getting feedback on this; esp.: is there a better way?  
> does anyone care?  can we make some kind of pseudo-standard?

I think all of this is overly complicated for edge case scenarios. 

> Generic method: 'methodCallChain( (no-args-methodname | [methodname, 
> arg*])* )':
>   - takes a list, where each element is an array, containing:
>    + an optional integer indicating which of multiple return values is to 
>      be used for the next method call  (default is 1).
>    + the method-name (a string)
>    + any input parameters for the method
>   The first method is applied to the receiving object.
>   If the method in question takes no args, and you only want the first arg 
> to be passed along the chain, you can just give the (string) name of the 
> method instead of the array.

That API is confusing and at best and could lead to unexpected behavior
if things are treated differently on the native side of things.  It
could prove to be a debugging nightmare.  Not to mention the bindings
would have to support this in a similar way.

> In combination, these allow:
> * Using *native* types in the remote process.

I would suspect a remote process would be created to take dbus types
into consideration or all of a sudden you have exported methods that
can't be used outside of the native bindings.

> * sending messages to simple-types (integers etc.), when they are the 
> return-value of  a method-call.  (but see below for a more general scheme)

But what messages would they support?

> * combining what would be multiple inter-process calls into a single one.

Why not just do this in the API of the service?

> An example:
>   Say my remote process (e.g. python) supports Bignums 
> (arbitrary-precision integers), and that /pgpinfo contains some PGP-key 
> information.
>   Now if /pgpinfo->key() returns a bignum so big that it doesn't fit in an 
> unsigned-64, then it will probably be encoded as a DBus object specific to 
> the python process.

You would send it over as a string I would guess.

>   But if it returns a bignum that *does* fit in a simple-type (e.g. 
> uint64), then the python<->dbus interface is likely to convert it to a 
> simple type.

We throw an error if we can't marshal it to a dbus type.  In this case
the bignum would have to be explicitly "cast" to a type object or
converted to a string.  The service should decide what to do with it.

>   Now what if I want to send a message to the key?  In the former case, 
> the message will go to python, but in the latter to my local 
> implementation.
>   e.g. /pgpinfo->key()->factorModulo(23940) may or may not fail depending 
> on the size of the key.
> 
> With the above-mentioned chaining, though, I can do
>   /pgpinfo->methodCallChain('key', ['factor', 23940])
> which will return the correct result.

Why not just /pgpinfo->factor_key(23940)?

>   This will also save a round-trip and possibly bignum-conversions.

so does the above and it is a lot nicer

<snip>
> 
>   I see much traffic on the DBus list regarding C bindings like GLib.  
> The content of this posting may not seem as relevant if you are calling 
> *out* to C.  But, if you are trying to interface languages where 
> "Everything is an Object" (e.g. Smalltalk), I think some solution of this 
> nature will be important.
> 

Sorry to be over critical of this idea but it does look like solution in
search of a problem.  I think well thought out API's is the solution to
the round trip problem as well as not using DBus for lowlevel
operations.  Keeping the bindings simple and maintainable is also a huge
goal that this would complicate.  Really DBus is not "the" technology
for lack of a better phase.  It is an enabler that enables other
technologies.  Adding something like this puts rules into DBus that I
believe should be left to the author of the API being wrapped by DBus.
For instance there was once talk of DBus types cascading so if a method
was expecting a 64 bit integer but the client sent over a 32 bit integer
the service would still accept it.  This was rejected because it
complicated DBus for little gain. 
 
-- 
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com