Thank you for your help! On Sun, Mar 1, 2009 at 10:23 PM, Jelle de Jong <jelledejong@xxxxxxxxxxxxx> wrote: > Alon Bar-Lev wrote: >> 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. > > Hi Alon, > > Maybe this tool can help you for the gui side of your problems, yes I > know its no command-line tool but its the best I can do for you. > > It's about the blueman tool: > http://lists.debian.org/debian-mentors/2009/02/msg00277.html > > I provide the link to the archive, because I sent some mail to the > thread. Maybe the bluez-gnome bluetooth-applet developers can read the > thread too and provide there opinion about the issues? > > Best regards, > > Jelle de Jong > -- 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
