glib object/method-based API

[Havoc Pennington]

On Mon, May 12, 2003 at 01:44:21PM +0100, Michael Meeks wrote: 
> 	One of the least elegant bits in ORBit2 stubs/skels is the return value
> handling; which is special cased for various reasons.
> 
> 	How do you plan to handle return values ? - simply a FOO_INT, &ret_val
> in the argument list ? if so - is the return value last ? and/or are you
> going to go for simple or multiple return values [ AFAIR language
> binding experience suggests single return values are easiest ].

The current code is just "no return values" (only out params).  We
could probably just convert one of the out params to a return value on
the stubs/skels level without affecting anything deeper. i.e. if the
"IDL" has a return value then it is treated as either the last or the
first out param. If not then the generated stub returns a bool for
error-set/no-error-set.

> 	Similarly the DBusPendingCall thing looks like it doesn't do return
> values

Well it just does out params, one of which you could pretend is the
return value if you wanted.

> ie. you want to call the CompleteNotify on broken connections, and
> returned data.

Right - but this happens automatically, since a broken connection
generates an error. The notification is called when the error message
arrives.

> Also - any async callback mechanism implicitely assumes
> some kind of event loop / dispatch mechansim - I believe you wanted to
> isolate that processing (?). I guess that can be fixed by
> dbus_pending_call_set_async_mainloop(GMainLoop *loop); or whatever - I
> guess you'd have a more advanced / wrapped scheme than that. Of course,
> a two stage async invoke/return processing setup approach has race
> problems but ...

The non-async code (without pending_call) does an isolated
dbus_connection_send_with_reply_and_block() (does not enter main loop
or call callbacks at all).

The async code does use the main loop (same main context passed in to
dbus_connection_setup_for_g_main()); it doesn't need a GMainLoop, it
just adds handlers to the GMainContext and waits for the app to
reenter its own main loop.

The point is that the app developer has choice between something
synchronous without reentrancy, or explicitly asynchronous with
obvious reentrancy (the reentrancy happens when they run the main loop
themselves). No main loop running is done "behind the scenes"

The synchronous code is thread safe, so you can run it out of a thread
if desired.

If you get into a "deadlock" situation with the synchronous API, you
have to either redesign the big picture, switch to async API, or add
threads.

> 	Also - the question of IDL syntax / format arises as soon as you have
> stubs/skels - but I'm sure all of that will arise later; what does D/COP
> do in that regard ?

DCOP parses a C++-like format I believe. See the HOWTO (which is in 
dbus/doc/ among other places). They have a special "async" keyword
which causes async stubs to be created.

The IDL format options I can imagine for the GLib bindings are
"something super cheesy like the glib-genmarshal thing" or "something
libIDL can parse."

Havoc