org.freedesktop.DBus.GLib.Async GLib specific ?

[frederic heem]

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 
is required.
> >> 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. 

______________________________________________________________________________