glib dbus bindings notes

[Havoc Pennington]

Hi,

On Tue, Mar 3, 2009 at 1:19 PM, David Zeuthen <david at fubar.dk> wrote:
> So I think maybe we want
>
>  GBusLowlevelConnection
>
> that is useful for all languages and then
>
>  GBusConnection
>
> for the C/GObject binding. But that's ugly. Ideas?

Maybe there's a ProxyManager or something which is higher level than
Connection? Or maybe the wrapper object on connection is the
high-level thing and then on lower level it's just DBusConnection
itself with some private data hanging off it, more like
hippo-dbus-helper?

> I guess your suggestion really is that EggDBusBus should be written by
> hand so we can put some extra client-side business logic into it; e.g.
> points 3. and 4; single instance, --replace support, all that jazz. And
> also make sure it can be bound to other languages like C without looking
> weird.

I probably didn't realize this file was generated.

My experience in apps is that almost all proxies require a wrapper
object; I usually have a "model" object representing the actual state
I'm tracking and then it keeps itself up-to-date with the remote state
using a proxy to make method calls and get changed signals. Anyway,
this seems like potentially another instance of the pattern, where
there might be a local Bus object which internally has a proxy for
talking to the remote bus, but keeps local state.

> macro or something. I don't know. I just don't think it's realistic to
> remove sync calls, by the same token, should we remove all the sync
> calls in GIO? I don't think so.

I've gotten more extreme on this over the years.
I had a rant at the bottom of http://log.ometer.com/2008-09.html

Basically my current opinion is that synchronous code in the main
thread of a GUI app should never ever get through patch review.

But... synchronous _APIs_ are still needed, so you can put them in
threads ;-) e.g. that's how GIO works, the async stuff calls the sync
stuff ...

I guess ultimately we have to allow app developers to shoot themselves
in the foot on this.

Havoc