Re: [arch-general] [arch-dev-public] request for dbus in core
Hi,
On Sat, Oct 11, 2008 at 3:09 PM, Jan de Groot <jan@jgc.homeip.net> wrote: A while ago I got a request from Thomas to make a stripped down dbus package that does not depend on libx11 so he could use it for wpa_supplicant which is also in core. As more and more services start to interact with this dbus thing, I'd like to move the new dbus-core package into core. This pulls in one extra dependency from extra, which is expat at this moment.
Which software is interacting with wpa_supplicant using dbus? Is it NetworkManager or something like that? The dbus service will be let disabled by default, right? It's worthy remembering that wpa_supplicant already supports IPC by using UNIX domain sockets or UDP sockets, which are Linux default/native stuff. (see [1]) On Sun, Oct 12, 2008 at 2:49 AM, James Rayner <iphitus@iphitus.org> wrote:
my support for [core], as an upcoming netcfg version will take advantage of the wpa_supplicant dbus interface.
Please avoid using dbus in netcfg. I like it because it's clean, KISS, and uses only default/native stuff. I can help integrating with UNIX domain sockets or UDP sockets if needed. [1] http://hostap.epitest.fi/wpa_supplicant/devel/wpa__ctrl_8c-source.html Best regards, Paulo Matias
On Sun, Oct 12, 2008 at 3:53 PM, Paulo Matias <matias@archlinux-br.org> wrote:
On Sun, Oct 12, 2008 at 2:49 AM, James Rayner <iphitus@iphitus.org> wrote:
my support for [core], as an upcoming netcfg version will take advantage of the wpa_supplicant dbus interface.
Please avoid using dbus in netcfg. I like it because it's clean, KISS, and uses only default/native stuff. I can help integrating with UNIX domain sockets or UDP sockets if needed.
[1] http://hostap.epitest.fi/wpa_supplicant/devel/wpa__ctrl_8c-source.html
It wasn't an immediate decision to use dbus and I did evaluate other options such as the aforementioned sockets interface. dbus is just as "default/native" if not more "native" than a custom control interface. These days, you'll struggle to find a system out there which doesnt at least have dbus installed. I picked the dbus setup as it's quicker for me to implement, easier to maintain in the long term, more KISS and easily the future for linux wireless configuration. dbus should be available in 2.2 and default in 3.0. In 3.0 the old interface will not be removed, instead renamed to "wireless-old" and so available for those who dislike dbus for some odd reason. If you want to implement a sockets interface, go for it. netcfg is designed to be modular, allowing a range of different interfaces implemented in any programming language (more in 2.2). James
Hi, On Mon, Oct 13, 2008 at 4:16 AM, James Rayner <iphitus@iphitus.org> wrote:
On Sun, Oct 12, 2008 at 3:53 PM, Paulo Matias <matias@archlinux-br.org> wrote:
On Sun, Oct 12, 2008 at 2:49 AM, James Rayner <iphitus@iphitus.org> wrote:
my support for [core], as an upcoming netcfg version will take advantage of the wpa_supplicant dbus interface.
Please avoid using dbus in netcfg. I like it because it's clean, KISS, and uses only default/native stuff. I can help integrating with UNIX domain sockets or UDP sockets if needed.
[1] http://hostap.epitest.fi/wpa_supplicant/devel/wpa__ctrl_8c-source.html
It wasn't an immediate decision to use dbus and I did evaluate other options such as the aforementioned sockets interface.
dbus is just as "default/native" if not more "native" than a custom control interface. These days, you'll struggle to find a system out there which doesnt at least have dbus installed. I picked the dbus setup as it's quicker for me to implement, easier to maintain in the long term, more KISS and easily the future for linux wireless configuration.
I agree the dbus interface is quicker to implement. This is why I offered help to implement the socket stuff if needed. Anyway, it would not take a lot of time, as the /dev/udp bash interface could be used. But if you think dbus is the future for Linux wireless configuration, and that wpa_supplicant would let another control interfaces unmaintained or even drop them, then it is really better to use dbus since now.
dbus should be available in 2.2 and default in 3.0. In 3.0 the old interface will not be removed, instead renamed to "wireless-old" and so available for those who dislike dbus for some odd reason.
Great. How will the new wireless interface be configured? DAEMONS=(dbus net-profiles) for those who want it being configured at boot up?
If you want to implement a sockets interface, go for it. netcfg is designed to be modular, allowing a range of different interfaces implemented in any programming language (more in 2.2).
Yes, I know. It's very a good job you had done in netcfg. It was very easy to implement a modified "wireless-ral" interface when I needed some "iwpriv" magic to use WPA in my ralink card, in the times I had to use rt73-cvs :) Thanks for the quick response and please don't understand me bad. I really appreciate your work, and I was only willing to help. If I was too boring, please forgive this purism and my fears. The first thing that had came to my mind when I read the "dbus in [core]" message was a lot of another services (like hal) being included after that, but no, this is not going to happen. Best regards, Paulo Matias
participants (2)
-
James Rayner
-
Paulo Matias