glib object/method-based API

[Michael Meeks]

Hi Havoc,

On Thu, 2003-05-08 at 05:32, Havoc Pennington wrote:
> I started some preliminary notes on the glib API client (method
> caller) side. The base API might be something like:

	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 ].

	Similarly the DBusPendingCall thing looks like it doesn't do return
values; although nothaving a DBusCallCompleteNotify signature perhaps it
does ;-) also, the semantics of when DBusCallCompleteNotify are called
can be quite interesting and will need explicit documenting.
ie. you want to call the CompleteNotify on broken connections, and
returned data. 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 ...

	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 ?

	HTH,

		Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot