to how it's handled in ACE
http://www.dre.vanderbilt.edu/Doxygen/Stable/ace/classACE__Future.html
One thing I did in EggDBus as compared to GIO, was to make the async
functions return a pending call id, e.g.
guint some_async_function (const gchar *stuff
On Sat, 2008-12-27 at 15:19 -0500, David Zeuthen wrote:
GFuture *future;
future = g_future_get (foo-pending_call);
g_object_set_data (future, other-stuff, other_stuff, g_object_unref);
and the GFuture object would be unreffed when the pending call is
finished.
I'd like to avoid having
This is a side-topic, raised by developments in handling DBus, but something I
feel is worth asking... Is there any mechanism for making working with
asynchronous stuff easier?
Quite often I've had a situation where I've needed to collect several pieces of
information from various
On Sat, 2008-12-27 at 04:21 -0500, Freddie Unpenstein wrote:
This is a side-topic, raised by developments in handling DBus, but
something I feel is worth asking... Is there any mechanism for making
working with asynchronous stuff easier?
Quite often I've had a situation where I've needed to
This is a side-topic, raised by developments in handling DBus, but something I
feel is worth asking... Is there any mechanism for making working with
asynchronous stuff easier?
Quite often I've had a situation where I've needed to collect several pieces of
information from various
).
- dbus_g_proxy_add_signal() is also a pain, for the same reason
You don't need these things when EggDBus; everything is automatically
set up for you (I agree it's unreasonable that you have to do this in
dbus-glib).
(And no, we don't currently use libffi - we could but even if we did, it
would
of http://live.gnome.org/MikkelKamstrup/GProxyIdea, in
which case the above export would become the more general
g_transport_export(my_trans, Pingable, myob);
Yeah. So you can easily do this with EggDBus right now. Suppose you had
a simple GInterface XesamService that applications offering search
multiple concurrent requests. But I think all that
is pretty doable; just haven't gotten around to it. Since you mention
D-Bus, note that even though the example in the bug uses gio, GFiber can
be used with EggDBus or any async API that uses the the async IO stack
from libgio (GAsyncResult
On Sat, 2008-12-27 at 04:21 -0500, Freddie Unpenstein wrote:
This is a side-topic, raised by developments in handling DBus, but
something I feel is worth asking... Is there any mechanism for making
working with asynchronous stuff easier?
Quite often I've had a situation where I've needed to
to how it's handled in ACE
http://www.dre.vanderbilt.edu/Doxygen/Stable/ace/classACE__Future.html
One thing I did in EggDBus as compared to GIO, was to make the async
functions return a pending call id, e.g.
guint some_async_function (const gchar *stuff
be called transports in the
terminology of http://live.gnome.org/MikkelKamstrup/GProxyIdea, in
which case the above export would become the more general
g_transport_export(my_trans, Pingable, myob);
Yeah. So you can easily do this with EggDBus right now. Suppose you had
a simple GInterface
before I started coding this.
One thing though... I am not completely able to grasp the relation of
EggDBus to GObject-Introspection... I would hope that they could be
highly integrated so that I could dynamically export an introspectable
GObjector something like that
Sure, if GObject
Hey David,
On Sun, 2008-12-21 at 21:48 -0500, David Zeuthen wrote:
Hey,
For the past 5 weeks or so, I've been working on a new (as compared to
dbus-glib) D-Bus binding for GObject. The work on this has finally
reached a stage where the code sufficiently complete and documented so I
thought
. Typically,
clients just rev the version they depend on; obviously with Telepathy
this is harder as you communicate with software on another system (I
*think* this is the way it works).
Anyway, with EggDBus you'd just introspect the object before you start
consuming interfaces (see below).
It's possibly
On Tue, 2008-12-23 at 10:37 -0500, David Zeuthen wrote:
If properties are not fast in Telepathy D-Bus services that might be a
problem not only for EggDBus, also for things like d-feet and possibly
for other D-Bus bindings that map to native properties, I don't know.
Either way
describing it. The code is here
Sweet!
I ended up using libtelepathy-glib generated GInterfaces in my latest
project for the server side bindings (after a patch if you don't use
properties they don't link to libtelepathy-glib). The GInterface model
is very nice to work with, so I'm glad EggDBus
This sounds wonderful. I have a couple of questions, though I am not
very experienced with D-Bus.
o Each D-Bus interface maps to a GInterface
So you can get a GSomething object that is a proxy for D-Bus object,
which implements GInterfaces for each D-Bus interface offered by that
object?
And
interface having to be individually requested asynchronously? That would
be nice.
Interface proxies are created on demand; e.g. only when used. There's no
automatic discovery happening.. there is however an easy to use
introspection facility
http://people.freedesktop.org/~david/eggdbus-0.1-docs
David Zeuthen wrote:
This mail is already too long but there's one more thing.
Yeah. Still digesting. But...
I have not done all that much with D-Bus, but one thing I noticed while
doing the libsoup 2.4 API rewrite was that, at a very high level, D-Bus
and XML-RPC are fairly similar, and so it
had this item for a while on the TODO list
o Very little of the core functionality is related to D-Bus; would
it be useful to have EggIpcProxy, EggIpcConnection, EggIpcMessage,
EggIpcMethodInvocation GInterfaces that all generated code uses?
Then the existing EggDBus* classes simply
David Zeuthen wrote:
Yeah. I think XML-RPC types can largely be considered a subset of the
D-Bus types. For the datetime we could add an extra ISO8601 data type or
something (don't think GTimeVal is enough; need to preserve the TZ I
think).
Nope, XML-RPC dateTimes are (unfortunately)
on the client side from
that. That's a lot of code that ideally could be generated by things
like EggDBus.)
Right. The way I work around that is by generating code in the
GInterface. It's not ideal, I really want method and signal dispatching
to be generic. I think libffi might help here.
I
://cgit.freedesktop.org/~david/eggdbus
First, let me briefly describe the motivation behind doing this work.
Well, there's a couple of reasons:
o The venerable dbus-glib bindings doesn't really make it easy (nor
enjoyable) to use D-Bus from GObject (especially not C). At the same
time other runtimes
23 matches
Mail list logo
