This patch adds support to hcid for PIN requests using D-BUS. (See
http://www.freedesktop.org/software/dbus/ if you don't know what D-BUS
is about.)
The advantage of this is that the UI for PIN entry runs as the logged-in
user, rather than root. There's then no need for the helper application
to try to guess the value for $DISPLAY or anything like that.
To use this mechanism, you need to configure bluez-utils with
--enable-dbus, and set pin-helper to "*dbus" in hcid.conf.
Thanks
p.
At 05:15 AM 6/25/2003, Marcel Holtmann wrote:
>Hi Max,
>Hi Stephen,
>
>> I think branch is CVS branch is probably a bad idea. Because we want
>> to change a lot of things like command names, etc. Which means lots
>> of file renames, CVS does not handle that.
>>
>> How about creating completely new modules
>> libs2
>> utils2
>> and start with the clean history.
>> We'll keep old ones around for a while but will only make minor fixes
>> to them.
>
>we have already discussed this and starting with new modules seemed to
>be the cleanest way. But we shouldn't name them libs2 and utils2,
>because we are already at version 2.x with the others. We should use
>libs3 and utils3 or maybe an unrelated to the version number suffix like
>"-ng".
I think version number of the current packages and '2' in libs2,utils2 are
unrelated. '2' just means second generation or something. New packages will
have new version numbers anyway.
So I vote for utils2 and libs2. People are used to things like glib2, libxml2.
libs3 would be something unusual :)
>If we agree on the new name, I will start to create the framework for the new modules.
Let's talk about the goals and objectives first.
Here is the list of things that I have in mind
1. API cleanup and redesign if necessary
Better function names, etc.
2. Better hotplug support
Device initialization via hotplug scripts
/etc/hotplug/bluetooth.agent, /etc/sysconfig/bluetooth, etc.
3. Neighborhood and security databases and API for them
Device names, PIN codes, Link keys, etc
Tools to access and modify those databases
4. Integrated SDP.
5. Better (more appropriate) names for Bluetooth command line utilities and daemons.
hciconfig -> btconfig
rfcomm -> btport
sdpd -> btsdpd
etc
6. Improved PIN helper support
D-Bus or something similar.
7. Improved documentation.
At least DoxyGen on headers and sources.
Comments ? Other ideas ?
Max
Hi Max,
Hi Stephen,
> I think branch is CVS branch is probably a bad idea. Because we want
> to change a lot of things like command names, etc. Which means lots
> of file renames, CVS does not handle that.
>
> How about creating completely new modules
> libs2
> utils2
> and start with the clean history.
> We'll keep old ones around for a while but will only make minor fixes
> to them.
we have already discussed this and starting with new modules seemed to
be the cleanest way. But we shouldn't name them libs2 and utils2,
because we are already at version 2.x with the others. We should use
libs3 and utils3 or maybe an unrelated to the version number suffix like
"-ng".
If we agree on the new name, I will start to create the framework for
the new modules.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 2003-06-24 at 18:31, Max Krasnyansky wrote:
> At 07:00 AM 6/24/2003, Stephen Crane wrote:
> >How do you want to start version 3? We'll need to keep the old utils
> >and libs around for a while. However I'd like to merge SDP in early:
> >there's a lot of duplicated effort (lists, etc.) which can be stripped
> >out.
> >
> >I have the first-cut at this merge in my local tree. However I don't
> >want to check it in on top of the old utils and libs --- unless you
> >think that's OK.
> >
> >So maybe the best way to proceed is to start a new branch in CVS?
>
> I think branch is CVS branch is probably a bad idea. Because we want
> to change a lot of things like command names, etc. Which means lots
> of file renames, CVS does not handle that.
>
> How about creating completely new modules
> libs2
> utils2
> and start with the clean history.
> We'll keep old ones around for a while but will only make minor fixes
> to them.
That works for me. You want to go first?
Steve
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 07:00 AM 6/24/2003, Stephen Crane wrote:
>How do you want to start version 3? We'll need to keep the old utils
>and libs around for a while. However I'd like to merge SDP in early:
>there's a lot of duplicated effort (lists, etc.) which can be stripped
>out.
>
>I have the first-cut at this merge in my local tree. However I don't
>want to check it in on top of the old utils and libs --- unless you
>think that's OK.
>
>So maybe the best way to proceed is to start a new branch in CVS?
I think branch is CVS branch is probably a bad idea. Because we want
to change a lot of things like command names, etc. Which means lots
of file renames, CVS does not handle that.
How about creating completely new modules
libs2
utils2
and start with the clean history.
We'll keep old ones around for a while but will only make minor fixes
to them.
Comments ?
Max
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sat, 2003-06-21 at 01:13, Max Krasnyansky wrote:
> We should really start working on 3.x libs and utils. There are so
> many things and ideas that we want to put in.
I've backed out the unwanted changes to SDP in CVS.
How do you want to start version 3? We'll need to keep the old utils
and libs around for a while. However I'd like to merge SDP in early:
there's a lot of duplicated effort (lists, etc.) which can be stripped
out.
I have the first-cut at this merge in my local tree. However I don't
want to check it in on top of the old utils and libs --- unless you
think that's OK.
So maybe the best way to proceed is to start a new branch in CVS?
Steve
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 2003-06-24 at 10:28, David Woodhouse wrote:
> Thanks for doing this. There are now packages in Red Hat Rawhide with
> this enabled.... volunteers to provide the GNOME and KDE GUI side for
> this welcomed...
Great. I made a GTK-based GUI for use in GPE; it should work fine in a
desktop environment too.
ftp://ftp.handhelds.org/pub/projects/gpe/source/bluez-pin-0.20.tar.gz
p.
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2003-06-19 at 17:42, Philip Blundell wrote:
> This patch adds support to hcid for PIN requests using D-BUS. (See
> http://www.freedesktop.org/software/dbus/ if you don't know what D-BUS
> is about.)
>
> The advantage of this is that the UI for PIN entry runs as the logged-in
> user, rather than root. There's then no need for the helper application
> to try to guess the value for $DISPLAY or anything like that.
>
> To use this mechanism, you need to configure bluez-utils with
> --enable-dbus, and set pin-helper to "*dbus" in hcid.conf.
Thanks for doing this. There are now packages in Red Hat Rawhide with
this enabled.... volunteers to provide the GNOME and KDE GUI side for
this welcomed...
--
dwmw2
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 09:42 AM 6/19/2003, Philip Blundell wrote:
>This patch adds support to hcid for PIN requests using D-BUS. (See
>http://www.freedesktop.org/software/dbus/ if you don't know what D-BUS
>is about.)
>
>The advantage of this is that the UI for PIN entry runs as the logged-in
>user, rather than root. There's then no need for the helper application
>to try to guess the value for $DISPLAY or anything like that.
>
>To use this mechanism, you need to configure bluez-utils with
>--enable-dbus, and set pin-helper to "*dbus" in hcid.conf.
Cool.
We should really start working on 3.x libs and utils. There are so
many things and ideas that we want to put in.
Max
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2003-06-19 at 17:42, Philip Blundell wrote:
> This patch adds support to hcid for PIN requests using D-BUS. (See
> http://www.freedesktop.org/software/dbus/ if you don't know what D-BUS
> is about.)
Cute.
+#define REQUEST_NAME "org.handhelds.gpe.bluez.pin-request"
Better suggestions welcome.
--
dwmw2
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, Jun 24, 2003 at 10:31:25AM -0700, Max Krasnyansky wrote:
>
> I think branch is CVS branch is probably a bad idea. Because we want
> to change a lot of things like command names, etc. Which means lots
> of file renames, CVS does not handle that.
Yea. Time to move to arch/tla from CVS.
--
Paul
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2003-09-04 at 22:18, David Woodhouse wrote:
> On Thu, 2003-06-19 at 17:42 +0100, Philip Blundell wrote:
> - | K_PINHELP PATH {
> + | K_PINHELP WORD {
>
> It also removes support for actually configuring a pin helper as before.
> Reverting the above removes support for the magic '*dbus' value.
Hm, right. I was under the impression that WORD was a superset of PATH,
but looking at the code again it seems I was mistaken about that.
Making the lexer more permissive about what characters can go in a PATH
would probably clear it up, and might not be a bad thing to do on
general principle, but the "*dbus" thing was always a bit of a crock
anyway. I've modified the patch to use a completely different keyword,
so you now replace the whole pin_helper ... line with a
"dbus_pin_helper" statement. That should remove any chance of ambiguity
and avoid altering the behaviour of existing config files.
> I suspect we should just be using a script wrapper around
> dbus-send, or a simple external program, rather than putting support for
> dbus directly into hcid.
For PIN entry that would be a reasonable solution, but there are other
ways in which I think it would be useful for hcid to support D-BUS
directly; for example, manipulating the list of paired devices and
turning discoverability on and off.
I don't think it should be hard to arrange for hcid to tolerate failure
to connect to dbus a little better. Try
http://handhelds.org/~pb/bluez-dbus-20030904.diff.gz and see if you get
on any better with that one.
p.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thu, 2003-06-19 at 17:42 +0100, Philip Blundell wrote:
> This patch adds support to hcid for PIN requests using D-BUS. (See
> http://www.freedesktop.org/software/dbus/ if you don't know what D-BUS
> is about.)
- | K_PINHELP PATH {
+ | K_PINHELP WORD {
It also removes support for actually configuring a pin helper as before.
Reverting the above removes support for the magic '*dbus' value.
+ if (hcid_dbus_init () == FALSE) {
+ syslog (LOG_ERR, "Unable to get on D-BUS");
+ exit (1);
... and then it disables support for running hcid on any system on which
dbus isn't actually active, even if not configured to _use_ dbus. :)
I suspect we should just be using a script wrapper around
dbus-send, or a simple external program, rather than putting support for
dbus directly into hcid.
--
dwmw2
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel