org.freedesktop.DBus.GLib.Async GLib specific ?
frederic.heem at telsey.it
Fri Sep 8 06:35:10 PDT 2006
Alle 15:15, venerdì 8 settembre 2006, Thiago Macieira ha scritto:
> frederic heem wrote:
> >Not yet, dbus-binding-tool has these feature, for the my application,
> >asynchronous call is mandatory. So either I modified dbusxml2cpp to
> > support asynchronous call or I dropped Qt on the client side use in
> > favor of glib binding. since I prefer Qt over glib, I'll go for the
> > first solution.
> I'd like to see the patch if possible. It might be interesting to add to a
> later version of the tool, as an optional switch.
Actually, the idea of a compiler switch is a better alternative for my
problem. Indeed, all client methods are asynchronous, so better a compiler
switch than marking every single methods with an annotation.
> I'd rather avoid
> introducing another annotation (dbusxml2cpp already has too many).
That's exactly what I've prosposed: to agree an a *unique* name for the
asynchronous annotation, for example org.freedesktop.DBus.Method.Async
Unfortunately, dbusxml2cpp documentation is scarse, is there a document for
dbusxml2cpp specific annotation ?
> >Why ? Could you comment with a valid reason ?
> >Do you know a project that uses dbus asynchronous call ? So far, google
> > found only one library that has one occurrence of the annotation
> >org.freedesktop.DBus.GLib.Async, then looking at the code shows they
> > misused this keyword, indeed, the notify_daemon_notify_handler is a
> > *synchronous* call, indeed, dbus_g_method_returns is called inside
> >notify_daemon_notify_handler !
> >So far, no one is really using the asynchronous annotation.
> Asynchronous in the sense that GLib uses means that the method call will
> be posted and control will return immediately to the caller. The callee's
> reply will come later, in a callback (in Qt terms, a slot).
> But QtDBus uses a restricted meaning of the term "asynchronous",
> indicating instead the NoReply concept: it means there will be no reply
> at all, so the caller doesn't need to wait for the completion from the
> callee. Method calls in this case are sent with the "no-reply" flag set,
> indicating that the callee doesn't have to bother sending a reply message
> either (which it is otherwise mandated to do).
The NoReply concept doesn't apply for my problem since an asynchronous reply
> >> You want to place a call using callWithCallback.
> >You missed the whole point, I don't want to write hand written code when
> > a tool can do it for me in a better and faster way, and without error.
> > The idea is to use dbusxml2cpp to generate callWithCallback calls
> > automatically.
> It was part of the requested features for QtDBus when I did one of its API
> Reviews with other Trolltech developers. But I deemed it too complex to
> be implemented in the initial version and, since most of the users of
> QtDBus will come from KDE DCOP-ported code (which had a very complex way
> of implementing this), I didn't judge it to be necessary from the outset.
> But, if you implemented the code, it might be interesting to apply it to
> the tool.
--- NOTICE ---
CONFIDENTIALITY - This email and any attachments are confidential and are
intended for the addressee only. If you have received this message by
mistake, please contact us immediately and then delete the message from your
system. You must not copy, distribute, disclose or act upon the contents of
this email. Thank you.
PERSONAL DATA PROTECTION (Law by Decree 30. 06.2003 n. 196) - Personal and
corporate data submitted will be used in a correct, transparent and lawful
manner. The data collected will be processed in paper or computerized form for
the performance of contractual and lawful obligations as well as for the
effective management of business relationship. Data may be disclosed, in Italy
or abroad, for the purpose above mentioned to third parties which cooperate
with Telsey, agents, banks, factoring companies, credit recovering companies,
credit insurance companies, professional and consultants, and shipping
companies. In relation to the same purposes, data may be processed by the
following classes of executors or processors: management; administration
department; logistics and purchase department; sales department; post sales
department quality department; R&D department; IT department; legal department.
The data processor is Telsey S.p.A. The data subject may exercise all the
rights set forth in art. 7 of Law by Decree 30. 06.2003 n. 196 as reported in
in the following link http://www.telsey.it/privacy.jsp.
More information about the dbus