On Sat, Feb 28, 2009 at 10:03 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > Hi, > > On Sat, Feb 28, 2009, Alon Bar-Lev wrote: >> I am sorry I post here, but there is no user mailing list specified at >> [1] while both links at [2] refer to this list. I will appreciate if >> you forward me to the right place. > > Nope, as far as I understand this list is intended for both developer > and user issues. Oh.. """linux-bluetooth This mailing list is for the kernel developer.""" Needs an update :) >> I try to figure out how to create bnep interface. It looks like one >> should have vast knowledge in dbus > > If you're a developer, then yes. If you're a user the interface has already > failed at the point where it requires you to know what "bnep" is :) I think that you have incorrect view of users/integrators/sysadmins. There are many levels of complexity... One is to write something like bluz, and the other is to create a single working entity out of many components. So developer of one solution can be a user of the other, and sysadmin can be a user of many etc... Imagin you are a sysadmin or a user of all solutions but bluez, and need to setup a working machine, if you don't have simple utilities you end up in being an expert in each of the components, or ends up with incomplete solution as you don't have enough time. Back in the CORBA time, at least we had decent command-line interface so that I could enumerate, create and call methods. dbus failed to provide such interface for automation. All I wanted is to connect two devices using bluez, using command-line. Using the basic layout, automation and no UI... tun, ppp, bridge are all working great, providing decent command-line interface and no extra dependencies (dbus). > As a user, you should ultimately be using some *user* interface (either > graphical or command line) which hides any complexities of the D-Bus > interface. All I know is dbus-send, do you have any other tool? > The big fault from the BlueZ project's side is that it hasn't > provided proper command-line user tools for its D-Bus interface. I think > one of the reasons for this is that the existing tools like hcitool and > hciconfig along with the python scripts that come with the source have > been regarded as "good enough". Can you please point me to a script in source tarball to created bnep interface? >> and/or python in order to achieve this goal. > > Why especially python? There's a plethora of different language bindings > available for D-Bus. You can find a list of them here: > http://www.freedesktop.org/wiki/Software/DBusBindings Again, there is a major difference between a simple script and starting dbus development. Why do I need to know dbus if I want to USE bluez? Well... I understand I need to start learning or just use PPP over rfcomm... At least I know how to set this up without dbus knowledge. >> Does anyone has a sample without python dependency (shell script) that >> can create bnep interface on both ends for hidden (explicit mac) devices? > > I'm not aware of any D-Bus binding for shell languages (like bash). > There's the generic dbus-send command line tool provided by D-Bus but it > won't get you very far with the more complex interfaces. Just out of > curiosity, what kind of system are you using that doesn't have python > available? Some embedded device perhaps? (in which case the border > between a user and developer starts to get quite blurred). A user is a user of a component, he can be a developer of other software. Nothing blurred. I just wanted to know that I understand correctly and I need to develop my own software in order to use basic functionality. I thought that like iproute2 support tan/tap it can support bnep and then all be happy :) But adding dbus dependency to core is not wise. >> Alternatively, can anyone please tell me what is the uuid parameter >> for org.bluez::org.bluez.Network::Connect? > > That's the Bluetooth UUID of the service you want to use. However the > interface will also accept "friendly" strings such as "nap" and "panu". > Admittedly doc/network-api.txt should be updated to list all of these > possibilities. It's much terse right now. Can you please tell me what is the friendly string to set up bnep interface to a specific device? >> Anyway... I think the requirement for people to use dbus is truly >> unusable... > > I'll assume you mean "user" when you say "people". You're right of > course. The D-Bus interface was never intended for users. It was created > for developers to build user interfaces and while GUI's are out of scope > for the BlueZ project at least a command-line tool should be available > for users not wanting or being able to deal with GUI's. Great... Need a sample... :) >> Providing simple solutions/scripts for common tasks is required. > > Agreed. Right now for many tasks you can use the legacy command line > tools and even the old daemons like pand if you wish. For the D-Bus > interface there are the python scripts within the source tree and in the > long run we should hopefully have a proper command line user tool for > the D-Bus interface. I don't understand, I thought the pand is not needed anymore, no daemon is needed, right? Or I miss something. Anyway, most distribution do not install pand anymore... Thank you, Alon. -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
