dbus_bus_get VS dbus_connection_open

[frederic heem]

Alle 21:11, venerdì 1 settembre 2006, hai scritto:
> frederic heem wrote:
> > Hi,
> > Using dbus_connection_open  instead of dbus_bus_get results in
> > significant differences. dbus_connection_open is used to avoid using the
> > already running system and session bus.
> > The problem is the that "org_freedesktop_DBus_request_name" method
> > returns the following error: "Client tried to send a message other than
> > Hello without being registered". Digging into the code shows that the
> > client code that uses "dbus_connection_open" also needs to call
> > "dbus_bus_register". Using dbus_bus_get internally calls
> > dbus_connection_open and dbus_bus_register. Why not invoking
> > dbus_bus_register inside dbus_connection_open ?
>
> The bus is only one possible remote process; you can also just open a
> connection to some random app, if you like. dbus_bus_get pretty much
> _is_ dbus_connection_open + dbus_bus_register.
>
No difference shall be be made between a standard bus such as the system and 
sesssion bus (dbus_bus_get()), and a user defined bus 
(dbus_connection_open()). They are both factory function that returns 
a "ready to use" connection, only the key to get the connection changes, a 
number or a string. The dbus-send and dbus-monitor clearly shows that at the 
moment, the code has to make an extra check if the bus is a user defined bus, 
this is not symmetrical and very error prone. 
Moreover, for the glib binding, dbus_g_register() doesn't exist, 
dbus_register() is not documented and anyway shall not be use in glib code 
because  it would break encapsulation.
Let's rename dbus_connection_open() to dbus_connection_create() and add  
dbus_connection_open() that does dbus_connection_create() + dbus_register().

 
> > Also, dbus-send and dbus-monitor have been modified to accept an address
> > name to use with dbus_connection_open. The path contains this
> > modifications.
>
> Thanks for the patch, some comments:
>   - CLI_OPTION_DBUS_ADDRESS probably shouldn't be a #define if none of
>     the other options are, I don't think it makes things clearer
Yes, indeed, but it make the code maintainable.
>   - the variables pcAddress, pcBus, etc. have the wrong naming convention
>     (fooBar vs. foo_bar)
Yes, I should have followed the dbus coding style, even though I definitely 
prefer the Hungarian notation for maintenance issue
>   - rather than == FALSE should use !
Is it a real mistake or just synthetic sugar ? 
>   - s/examples invocation/example invocations/
>   - I believe the code crashes if --address has no '=' after it?
Yes, there is a mistake. But the why a standard function to parse parameter is 
not used ? get_opt() ? 
>   - "return (-1)" should be "exit (1)" to match the other code
It's a cut'n'paste bug, anyway this portion of code shouldn't be there, 
dbus_connection_open() shall really opens the connection, not just creates it.

> Havoc


______________________________________________________________________________

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

______________________________________________________________________________