Re: Version 3 libs/utils

Re: Version 3 libs/utils

[Max Krasnyansky]

[Resent because nobody replied]

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

[Bluez-devel] Re: Version 3 libs/utils

[Marcel Holtmann]

Hi Max,

> [Resent because nobody replied]

I read your post, but don't got enough time to reply :(

> >> 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 :)

I prefer using the -ng suffix for the CVS repositories, so we can decide
later how we proceed with the name/version of the packages.

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

I already started to implement the missing HCI defines and functions.
And we should clean this up and check the ordering. With Bluetooth 1.2
we will get some more.

The "timeout" parameter is not needed by many functions. Kill it and use
some global timeout settings. But functions like the name resolv need a
bigger timeout, so we must take care of this.

The inquiry must be rewritten to take care of Bluetooth devices that
report BDADDR more than once.

> 2. Better hotplug support
>         Device initialization via hotplug scripts
>         /etc/hotplug/bluetooth.agent, /etc/sysconfig/bluetooth, etc.

One clean /etc/init.d/bluetooth, because I don't like the current way of
multiple init scripts which are used by the Debian packages.

> 3. Neighborhood and security databases and API for them
>         Device names, PIN codes, Link keys, etc
>         Tools to access and modify those databases

What about a Bluetooth daemon (for exmaple btmgr) which integrates the
security manager and the sdpd. It can also store an userspace Bluetooth
inquiry cache, name database and remote SDP cache. The local
configuration (like local device name) for example can also modified
through this daemon and restored on next boot, which is good for
handheld devices. The access can be done through a defined protocol over
unix sockets.

> 4. Integrated SDP.

The SDP API should be get more shortcuts for often needed routines, like
getting service name and PSM number or RFCOMM channel. Maybe it is a
good idea to have some profile specific SDP functions, which get the
most needed information for a profile and stores them in its own data
structure.

> 5. Better (more appropriate) names for Bluetooth command line utilities and daemons.
>         hciconfig -> btconfig
>         rfcomm -> btport
>         sdpd -> btsdpd
>         etc

I think we should have one tool (for example btconfig) which is staticly
linked with the Bluetooth library and can do all the configuration
stuff. This includes HCI, RFCOMM, BNEP etc. and such a tool should be
used by the bluetooth.agent and can be placed in an initrd.

And we should keep the old names (or programs) for compat reasons.

> 6. Improved PIN helper support
>         D-Bus or something similar.

We need some really good stuff here. The Gnome Desktop makes some
progress in integrating Bluetooth and we should also take care of it.

> 7. Improved documentation. 
>         At least DoxyGen on headers and sources.

Some kind of "Bluetooth Programing Manual" would be fine :)

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: Version 3 libs/utils

[Stephen Crane]

On Wed, 2003-07-02 at 02:01, Marcel Holtmann wrote:
> > >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 :)
> 
> I prefer using the -ng suffix for the CVS repositories, so we can decide
> later how we proceed with the name/version of the packages.

How about the suffix "+"? This isn't rocket science you know :-) I
really don't care what is used.

> > >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.
> 
> I already started to implement the missing HCI defines and functions.
> And we should clean this up and check the ordering. With Bluetooth 1.2
> we will get some more.

Yeah perhaps we could do a cleanup of the names along the lines of SDP.
(Then again maybe that's not needed but if it is it should happen at the
start.)

> The "timeout" parameter is not needed by many functions. Kill it and use
> some global timeout settings. But functions like the name resolv need a
> bigger timeout, so we must take care of this.
> 
> The inquiry must be rewritten to take care of Bluetooth devices that
> report BDADDR more than once.

Asynchronous interface to inquiry?

> > 2. Better hotplug support
> >         Device initialization via hotplug scripts
> >         /etc/hotplug/bluetooth.agent, /etc/sysconfig/bluetooth, etc.
> 
> One clean /etc/init.d/bluetooth, because I don't like the current way of
> multiple init scripts which are used by the Debian packages.
> 
> > 3. Neighborhood and security databases and API for them
> >         Device names, PIN codes, Link keys, etc
> >         Tools to access and modify those databases
> 
> What about a Bluetooth daemon (for exmaple btmgr) which integrates the
> security manager and the sdpd. It can also store an userspace Bluetooth
> inquiry cache, name database and remote SDP cache. The local
> configuration (like local device name) for example can also modified
> through this daemon and restored on next boot, which is good for
> handheld devices. The access can be done through a defined protocol over
> unix sockets.

I quite like this idea, except the SDP server functionality won't be
needed for some devices (e.g., handhelds).

> > 4. Integrated SDP.
> 
> The SDP API should be get more shortcuts for often needed routines, like
> getting service name and PSM number or RFCOMM channel. Maybe it is a
> good idea to have some profile specific SDP functions, which get the
> most needed information for a profile and stores them in its own data
> structure.

I would like to see C++ wrappers around the commonly used functions.
Much though I loathe the language itself, the SymbianOS code for
manipulating data-elements is quite succinct.

> > 5. Better (more appropriate) names for Bluetooth command line utilities and daemons.
> >         hciconfig -> btconfig
> >         rfcomm -> btport
> >         sdpd -> btsdpd
> >         etc
> 
> I think we should have one tool (for example btconfig) which is staticly
> linked with the Bluetooth library and can do all the configuration
> stuff. This includes HCI, RFCOMM, BNEP etc. and such a tool should be
> used by the bluetooth.agent and can be placed in an initrd.
> 
> And we should keep the old names (or programs) for compat reasons.
> 
> > 6. Improved PIN helper support
> >         D-Bus or something similar.
> 
> We need some really good stuff here. The Gnome Desktop makes some
> progress in integrating Bluetooth and we should also take care of it.
> 
> > 7. Improved documentation. 
> >         At least DoxyGen on headers and sources.
> 
> Some kind of "Bluetooth Programing Manual" would be fine :)

Err, or even, the mythical "one true how-to" :-)

Steve
-- 
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
steve.crane@rococosoft.com +353-1-6601315 (ext 209)

[Bluez-devel] Re: Version 3 libs/utils

[Marcel Holtmann]

Hi Stephen,

> > I prefer using the -ng suffix for the CVS repositories, so we can decide
> > later how we proceed with the name/version of the packages.
> 
> How about the suffix "+"? This isn't rocket science you know :-) I
> really don't care what is used.

it isn't important, but we should take care of not confusing the people.
And this is the only argument against the "2" suffix, because non
developer tend to mix module name with version number :(

And about the "+" - no special chars please, because they always cause
troubles you don't think of at the moment.

> > I already started to implement the missing HCI defines and functions.
> > And we should clean this up and check the ordering. With Bluetooth 1.2
> > we will get some more.
> 
> Yeah perhaps we could do a cleanup of the names along the lines of SDP.
> (Then again maybe that's not needed but if it is it should happen at the
> start.)

So maybe this is a good starting point. After I included all HCI
definition into the current CVS, we can fork and start the new version.

Everybody can help here. If you found a HCI command or event definition
which is not in the current CVS version of the libs package. Please send
me a patch and save me some time.

> > The "timeout" parameter is not needed by many functions. Kill it and use
> > some global timeout settings. But functions like the name resolv need a
> > bigger timeout, so we must take care of this.
> > 
> > The inquiry must be rewritten to take care of Bluetooth devices that
> > report BDADDR more than once.
> 
> Asynchronous interface to inquiry?

Yes, of course. I forgot this point. A common inquiry interface can
maybe also included into btmgr and forward inquiry event to the
application. Any ideas how to implement this in a clean way?

> > What about a Bluetooth daemon (for exmaple btmgr) which integrates the
> > security manager and the sdpd. It can also store an userspace Bluetooth
> > inquiry cache, name database and remote SDP cache. The local
> > configuration (like local device name) for example can also modified
> > through this daemon and restored on next boot, which is good for
> > handheld devices. The access can be done through a defined protocol over
> > unix sockets.
> 
> I quite like this idea, except the SDP server functionality won't be
> needed for some devices (e.g., handhelds).

This is not the truth. If you want to connect from a Windows based iPAQ
to a Bluetooth enabled Zaurus and transfer files over OBEX you need a
SDP server on your Zaurus.

But an option to disable it for people who know what they are doing
seems to be a good idea.

> > The SDP API should be get more shortcuts for often needed routines, like
> > getting service name and PSM number or RFCOMM channel. Maybe it is a
> > good idea to have some profile specific SDP functions, which get the
> > most needed information for a profile and stores them in its own data
> > structure.
> 
> I would like to see C++ wrappers around the commonly used functions.
> Much though I loathe the language itself, the SymbianOS code for
> manipulating data-elements is quite succinct.

I don't know much about C++, but we don't want to use C++ in any core
library or tool. The Bluetooth library itself should be usable with C++
(as it is today), but if you need extra stuff it must be included in an
extra library.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: Version 3 libs/utils

[Max Krasnyansky]

I finally have some time to read bluez mailing list. 
Sorry for being ridiculously slow.

At 06:01 PM 7/1/2003, Marcel Holtmann 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.
>> >> 
>> >> 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 :)
>
>I prefer using the -ng suffix for the CVS repositories, so we can decide
>later how we proceed with the name/version of the packages.

I still think utils2 is better. Let's just go with that. You don't seem to
have very strong preference. Other folks seem to be ok with it too.
So utils2 and libs2. I'll create top level CVS modules.

>> >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.
>
>I already started to implement the missing HCI defines and functions.
>And we should clean this up and check the ordering. With Bluetooth 1.2
>we will get some more.
>
>The "timeout" parameter is not needed by many functions. Kill it and use
>some global timeout settings. But functions like the name resolv need a
>bigger timeout, so we must take care of this.
>
>The inquiry must be rewritten to take care of Bluetooth devices that
>report BDADDR more than once.
Sounds good. Let's keep timeout for hci_send_req().

>> 2. Better hotplug support
>>         Device initialization via hotplug scripts
>>         /etc/hotplug/bluetooth.agent, /etc/sysconfig/bluetooth, etc.
>
>One clean /etc/init.d/bluetooth, because I don't like the current way of
>multiple init scripts which are used by the Debian packages.
/etc/init.d/bluetooth is not enough. We have to have /etc/hotplug/bluetooth.agent 
for hotplug. And it has to read configuration options like devices settings, etc.
That stuff will be stored in /etc/sysconfig/bluetooth.

>> 3. Neighborhood and security databases and API for them
>>         Device names, PIN codes, Link keys, etc
>>         Tools to access and modify those databases
>
>What about a Bluetooth daemon (for exmaple btmgr) which integrates the
>security manager and the sdpd. It can also store an userspace Bluetooth
>inquiry cache, name database and remote SDP cache. The local
>configuration (like local device name) for example can also modified
>through this daemon and restored on next boot, which is good for
>handheld devices. The access can be done through a defined protocol over
>unix sockets.
In general I don't like a 'kitchen sink' approach. Security manager, device names, etc
is fine. But SDP is unrelated service. I'd keep SDP separate. 
Also I don't see a need for user space inquiry cache. I guess you mean name database or
something.

>> 4. Integrated SDP.
>
>The SDP API should be get more shortcuts for often needed routines, like
>getting service name and PSM number or RFCOMM channel. Maybe it is a
>good idea to have some profile specific SDP functions, which get the
>most needed information for a profile and stores them in its own data
>structure.
Agree.

>> 5. Better (more appropriate) names for Bluetooth command line utilities and daemons.
>>         hciconfig -> btconfig
>>         rfcomm -> btport
>>         sdpd -> btsdpd
>>         etc
>
>I think we should have one tool (for example btconfig) which is staticly
>linked with the Bluetooth library and can do all the configuration
>stuff. This includes HCI, RFCOMM, BNEP etc. and such a tool should be
>used by the bluetooth.agent and can be placed in an initrd.
NO NO NO :-). We're going to have separate tools. hciconfig for example
needs to be separate from rfcomm and pand. There is no questions about that. 
If you absolutely need a single binary we could use Busybox way of combining
things into a single binary.

>And we should keep the old names (or programs) for compat reasons.
Yep.

>> 6. Improved PIN helper support
>>         D-Bus or something similar.
>
>We need some really good stuff here. The Gnome Desktop makes some
>progress in integrating Bluetooth and we should also take care of it.
I guess it will be via dbus or whatever other messaging supported by GUIs.

>> 7. Improved documentation. 
>>         At least DoxyGen on headers and sources.
>
>Some kind of "Bluetooth Programing Manual" would be fine :)
Sure. But who's going to write it ? ;-) 
If we use doxygen we'll at least have API reference.

Max

Re: Version 3 libs/utils

[Max Krasnyansky]

At 01:34 AM 7/2/2003, Stephen Crane wrote:
>> > So I vote for utils2 and libs2. People are used to things like glib2, libxml2.
>> > libs3 would be something unusual :)
>> 
>> I prefer using the -ng suffix for the CVS repositories, so we can decide
>> later how we proceed with the name/version of the packages.
>
>How about the suffix "+"? This isn't rocket science you know :-) I
>really don't care what is used.
Good (that you don't care :)). We'll go with utils2 and libs2. In fact I already created them
in CVS.

>> > >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.
>> 
>> I already started to implement the missing HCI defines and functions.
>> And we should clean this up and check the ordering. With Bluetooth 1.2
>> we will get some more.
>
>Yeah perhaps we could do a cleanup of the names along the lines of SDP.
>(Then again maybe that's not needed but if it is it should happen at the
>start.)
Yep. I did a lot of HCI header cleanup in 2.5 kernel.

>> The "timeout" parameter is not needed by many functions. Kill it and use
>> some global timeout settings. But functions like the name resolv need a
>> bigger timeout, so we must take care of this.
>> 
>> The inquiry must be rewritten to take care of Bluetooth devices that
>> report BDADDR more than once.
>
>Asynchronous interface to inquiry?
Yep.

>> > 3. Neighborhood and security databases and API for them
>> >         Device names, PIN codes, Link keys, etc
>> >         Tools to access and modify those databases
>> 
>> What about a Bluetooth daemon (for exmaple btmgr) which integrates the
>> security manager and the sdpd. It can also store an userspace Bluetooth
>> inquiry cache, name database and remote SDP cache. The local
>> configuration (like local device name) for example can also modified
>> through this daemon and restored on next boot, which is good for
>> handheld devices. The access can be done through a defined protocol over
>> unix sockets.
>
>I quite like this idea, except the SDP server functionality won't be
>needed for some devices (e.g., handhelds).
Agreed.

>> > 4. Integrated SDP.
>> 
>> The SDP API should be get more shortcuts for often needed routines, like
>> getting service name and PSM number or RFCOMM channel. Maybe it is a
>> good idea to have some profile specific SDP functions, which get the
>> most needed information for a profile and stores them in its own data
>> structure.
>
>I would like to see C++ wrappers around the commonly used functions.
>Much though I loathe the language itself, the SymbianOS code for
>manipulating data-elements is quite succinct.
Sure.

>> > 7. Improved documentation. 
>> >         At least DoxyGen on headers and sources.
>> 
>> Some kind of "Bluetooth Programing Manual" would be fine :)
>
>Err, or even, the mythical "one true how-to" :-)
:)

Max

Re: Version 3 libs/utils

[Max Krasnyansky]

At 09:29 AM 7/2/2003, Marcel Holtmann wrote:
 
>> Asynchronous interface to inquiry?
>
>Yes, of course. I forgot this point. A common inquiry interface can
>maybe also included into btmgr and forward inquiry event to the
>application. Any ideas how to implement this in a clean way?
Should be easy. And there is no need to go via btmgr.
HCI core can simply filter hci_inquiry command and drop it if inquiry is already
in progress. Applications will simply listen on raw socket and invoke callbacks 
for each inquiry_info event.

Max

[Bluez-devel] Re: Version 3 libs/utils

[Marcel Holtmann]

Hi Max,

> >> What about a Bluetooth daemon (for exmaple btmgr) which integrates the
> >> security manager and the sdpd. It can also store an userspace Bluetooth
> >> inquiry cache, name database and remote SDP cache. The local
> >> configuration (like local device name) for example can also modified
> >> through this daemon and restored on next boot, which is good for
> >> handheld devices. The access can be done through a defined protocol over
> >> unix sockets.
> >
> >I quite like this idea, except the SDP server functionality won't be
> >needed for some devices (e.g., handhelds).
> Agreed.

not agreed.

Try to connect with a Windows machine to a Linux based handheld to
transfer files over OBEX. You need a SDP server on your Linux handheld.
Only the real client only devices need no SDP server and these are
special cases or applications.

Regards

Marcel




-------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Re: Version 3 libs/utils

[Marcel Holtmann]

Hi Max,

> >I already started to implement the missing HCI defines and functions.
> >And we should clean this up and check the ordering. With Bluetooth 1.2
> >we will get some more.
> >
> >The "timeout" parameter is not needed by many functions. Kill it and use
> >some global timeout settings. But functions like the name resolv need a
> >bigger timeout, so we must take care of this.
> >
> >The inquiry must be rewritten to take care of Bluetooth devices that
> >report BDADDR more than once.
> Sounds good. Let's keep timeout for hci_send_req().

yes of course. The general functions should keep the timeout parameter.

> >One clean /etc/init.d/bluetooth, because I don't like the current way of
> >multiple init scripts which are used by the Debian packages.
> /etc/init.d/bluetooth is not enough. We have to have /etc/hotplug/bluetooth.agent 
> for hotplug. And it has to read configuration options like devices settings, etc.
> That stuff will be stored in /etc/sysconfig/bluetooth.

You are right with that, but this was not what I meant. There should be
only one /etc/init.d/bluetooth startup script (not many like in the
Debian packages). This script should read the basic options from
/etc/sysconfig/bluetoth (RedHat) or /etc/default/bluetooth (Debian) and
get some extra options from /etc/bluetooth/. This is for general
startup. Each device specific stuff must be done with bluetooth.agent
script.

> >What about a Bluetooth daemon (for exmaple btmgr) which integrates the
> >security manager and the sdpd. It can also store an userspace Bluetooth
> >inquiry cache, name database and remote SDP cache. The local
> >configuration (like local device name) for example can also modified
> >through this daemon and restored on next boot, which is good for
> >handheld devices. The access can be done through a defined protocol over
> >unix sockets.
> In general I don't like a 'kitchen sink' approach. Security manager, device names, etc
> is fine. But SDP is unrelated service. I'd keep SDP separate. 

The SDP server is needed in most cases (see my other post). Why do not
make it smart and integrate it. We need to keep track of different
Bluetooth adapters attached to one host, so if we have one daemon, the
SDP server can profite from a general approach.

This idea is not completly designed, but it makes sense to me, because
in the long term, we can't live without SDP.

> Also I don't see a need for user space inquiry cache. I guess you mean name database or
> something.

I meant inquiry cache in a little bit wider range. It should store
device specific information, but also the inquiry results. I think it is
a good idea, that the library also have access to the inquiry results,
because name resolves can be much faster if you fill in the paramters
from an inquiry (even if the clock drifts).

> >I think we should have one tool (for example btconfig) which is staticly
> >linked with the Bluetooth library and can do all the configuration
> >stuff. This includes HCI, RFCOMM, BNEP etc. and such a tool should be
> >used by the bluetooth.agent and can be placed in an initrd.
> NO NO NO :-). We're going to have separate tools. hciconfig for example
> needs to be separate from rfcomm and pand. There is no questions about that. 
> If you absolutely need a single binary we could use Busybox way of combining
> things into a single binary.

We will never agree on this point :)

Regards

Marcel




-------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Version 3 libs/utils

[Max Krasnyansky]

At 05:33 PM 7/17/2003, Marcel Holtmann wrote:
>Hi Max,
>
>> >> What about a Bluetooth daemon (for exmaple btmgr) which integrates the
>> >> security manager and the sdpd. It can also store an userspace Bluetooth
>> >> inquiry cache, name database and remote SDP cache. The local
>> >> configuration (like local device name) for example can also modified
>> >> through this daemon and restored on next boot, which is good for
>> >> handheld devices. The access can be done through a defined protocol over
>> >> unix sockets.
>> >
>> >I quite like this idea, except the SDP server functionality won't be
>> >needed for some devices (e.g., handhelds).
>> Agreed.
>
>not agreed.
>
>Try to connect with a Windows machine to a Linux based handheld to
>transfer files over OBEX. You need a SDP server on your Linux handheld.
>Only the real client only devices need no SDP server and these are
>special cases or applications.

I don't use OBEX and my laptop doesn't provide any other Bluetooth service.

Max



-------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Version 3 libs/utils

[Max Krasnyansky]

At 05:51 PM 7/17/2003, Marcel Holtmann wrote:
>> >What about a Bluetooth daemon (for exmaple btmgr) which integrates the
>> >security manager and the sdpd. It can also store an userspace Bluetooth
>> >inquiry cache, name database and remote SDP cache. The local
>> >configuration (like local device name) for example can also modified
>> >through this daemon and restored on next boot, which is good for
>> >handheld devices. The access can be done through a defined protocol over
>> >unix sockets.
>> In general I don't like a 'kitchen sink' approach. Security manager, device names, etc
>> is fine. But SDP is unrelated service. I'd keep SDP separate. 
>
>The SDP server is needed in most cases (see my other post). Why do not
>make it smart and integrate it. We need to keep track of different
>Bluetooth adapters attached to one host, so if we have one daemon, the
>SDP server can profite from a general approach.
>
>This idea is not completly designed, but it makes sense to me, because
>in the long term, we can't live without SDP.
I'd keep it separate. But I don't have very strong feeling about this one :).

>> Also I don't see a need for user space inquiry cache. I guess you mean name database or
>> something.
>
>I meant inquiry cache in a little bit wider range. It should store
>device specific information, but also the inquiry results. I think it is
>a good idea, that the library also have access to the inquiry results,
>because name resolves can be much faster if you fill in the paramters
>from an inquiry (even if the clock drifts).
Yeah, I call it device database :).

>> >I think we should have one tool (for example btconfig) which is staticly
>> >linked with the Bluetooth library and can do all the configuration
>> >stuff. This includes HCI, RFCOMM, BNEP etc. and such a tool should be
>> >used by the bluetooth.agent and can be placed in an initrd.
>> NO NO NO :-). We're going to have separate tools. hciconfig for example
>> needs to be separate from rfcomm and pand. There is no questions about that. 
>> If you absolutely need a single binary we could use Busybox way of combining
>> things into a single binary.
>
>We will never agree on this point :)
No. But at some point you'll realize that I'm right :). It sure won't happen the other 
way though ;-).
At least you're not saying - lets combine 'ifconfig', 'route', 'ip', 'iptables', 'netstat',
into a single tool :).

Max



-------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Version 3 libs/utils

[Marcel Holtmann]

Hi Max,

> >> >I quite like this idea, except the SDP server functionality won't be
> >> >needed for some devices (e.g., handhelds).
> >> Agreed.
> >
> >not agreed.
> >
> >Try to connect with a Windows machine to a Linux based handheld to
> >transfer files over OBEX. You need a SDP server on your Linux handheld.
> >Only the real client only devices need no SDP server and these are
> >special cases or applications.
> 
> I don't use OBEX and my laptop doesn't provide any other Bluetooth service.

but some laptops will provide Bluetooth services to others ;)

Anyway, if I remember correctly, the status channel of HCRP will
connected from the server to client. And the server ask the client for
the PSM of status channel by SDP.

And don't forget the stupid mRouter callback mechanism of the Symbian
Bluetooth phones.

Regards

Marcel




-------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Version 3 libs/utils

[Marcel Holtmann]

Hi Max,

> >The SDP server is needed in most cases (see my other post). Why do not
> >make it smart and integrate it. We need to keep track of different
> >Bluetooth adapters attached to one host, so if we have one daemon, the
> >SDP server can profite from a general approach.
> >
> >This idea is not completly designed, but it makes sense to me, because
> >in the long term, we can't live without SDP.
> I'd keep it separate. But I don't have very strong feeling about this one :).

let's see how it goes. If we have more details on how the new Bluetooth
master server will look like, we may can make a better decission.

> >> Also I don't see a need for user space inquiry cache. I guess you mean name database or
> >> something.
> >
> >I meant inquiry cache in a little bit wider range. It should store
> >device specific information, but also the inquiry results. I think it is
> >a good idea, that the library also have access to the inquiry results,
> >because name resolves can be much faster if you fill in the paramters
> >from an inquiry (even if the clock drifts).
> Yeah, I call it device database :).

Should we keep the kernel inquiry interface? The kernel inside inquiry
cache is a nice thing and works in the background like a charm :)

What about the idea to integrate the inquiry into the library or into
the Bluetooth master daemon.

> >> >I think we should have one tool (for example btconfig) which is staticly
> >> >linked with the Bluetooth library and can do all the configuration
> >> >stuff. This includes HCI, RFCOMM, BNEP etc. and such a tool should be
> >> >used by the bluetooth.agent and can be placed in an initrd.
> >> NO NO NO :-). We're going to have separate tools. hciconfig for example
> >> needs to be separate from rfcomm and pand. There is no questions about that. 
> >> If you absolutely need a single binary we could use Busybox way of combining
> >> things into a single binary.
> >
> >We will never agree on this point :)
> No. But at some point you'll realize that I'm right :). It sure won't happen the other 
> way though ;-).

We will see :)

> At least you're not saying - lets combine 'ifconfig', 'route', 'ip', 'iptables', 'netstat',
> into a single tool :).

You always hit me with this point, but what about "netstat -r" and
"netstat -i". Some things can be done with two different tools, but from
the kernel side they are all the same.

Regards

Marcel




-------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Version 3 libs/utils

[Max Krasnyansky]

At 03:40 AM 7/22/2003, Marcel Holtmann wrote:
>Hi Max,
>
>> >The SDP server is needed in most cases (see my other post). Why do not
>> >make it smart and integrate it. We need to keep track of different
>> >Bluetooth adapters attached to one host, so if we have one daemon, the
>> >SDP server can profite from a general approach.
>> >
>> >This idea is not completly designed, but it makes sense to me, because
>> >in the long term, we can't live without SDP.
>> I'd keep it separate. But I don't have very strong feeling about this one :).
>
>let's see how it goes. If we have more details on how the new Bluetooth
>master server will look like, we may can make a better decission.
Sounds good.

>> >> Also I don't see a need for user space inquiry cache. I guess you mean name database or
>> >> something.
>> >
>> >I meant inquiry cache in a little bit wider range. It should store
>> >device specific information, but also the inquiry results. I think it is
>> >a good idea, that the library also have access to the inquiry results,
>> >because name resolves can be much faster if you fill in the paramters
>> >from an inquiry (even if the clock drifts).
>> Yeah, I call it device database :).
>
>Should we keep the kernel inquiry interface? The kernel inside inquiry
>cache is a nice thing and works in the background like a charm :)
You mean HCI_INQUIRY ioctl, right ? I'm not sure about that one.
We'll certainly keep inquiry cache. Cache doesn't really depend on ioctl.

>What about the idea to integrate the inquiry into the library or into
>the Bluetooth master daemon.
I don't see a need for forwarding inquiry results from a daemon. It can be 
done in a simple way in the kernel, just like I explained in prev emails
(ie kernel parsing hci_inquiry command).

>> At least you're not saying - lets combine 'ifconfig', 'route', 'ip', 'iptables', 'netstat',
>> into a single tool :).
>
>You always hit me with this point, but what about "netstat -r" and
>"netstat -i". Some things can be done with two different tools, but from
>the kernel side they are all the same.
Sure. Sometimes it makes sense. hcitool dev shows device list for example. 

Max

Re: [Bluez-devel] Re: Version 3 libs/utils

[Marcel Holtmann]

Hi Max,

> >Should we keep the kernel inquiry interface? The kernel inside inquiry
> >cache is a nice thing and works in the background like a charm :)
> You mean HCI_INQUIRY ioctl, right ? I'm not sure about that one.
> We'll certainly keep inquiry cache. Cache doesn't really depend on ioctl.

yes, I meant the ioctl. The kernel inquiry cache is a nice thing and
maybe we should provide read only access to it from the userspace.

> >What about the idea to integrate the inquiry into the library or into
> >the Bluetooth master daemon.
> I don't see a need for forwarding inquiry results from a daemon. It can be 
> done in a simple way in the kernel, just like I explained in prev emails
> (ie kernel parsing hci_inquiry command).

My concern is the HCI_INQUIRY ioctl, because it don't really fits the
possibilities and specification details of the inquiry command. But I
don't know what the best way is here and with Bluetooth 1.2 we can also
get the RSSI from an inquiry result.

At the moment I think additional ioctl's for accessing the inquiry cache
will make it possible to use the inquiry command in a more dynamic way:

	- get number of inquiry cache entries
	- copy first n inquiry cache entries to my buffer
	- flush inquiry cache

Comments? Ideas?

Regards

Marcel




-------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Version 3 libs/utils

[Max Krasnyansky]

At 02:33 PM 7/22/2003, Marcel Holtmann wrote:
>Hi Max,
>
>> >Should we keep the kernel inquiry interface? The kernel inside inquiry
>> >cache is a nice thing and works in the background like a charm :)
>> You mean HCI_INQUIRY ioctl, right ? I'm not sure about that one.
>> We'll certainly keep inquiry cache. Cache doesn't really depend on ioctl.
>
>yes, I meant the ioctl. The kernel inquiry cache is a nice thing and
>maybe we should provide read only access to it from the userspace.
Sure. We already have it in 2.6
        cat /proc/bluetooth/hci/0/inquiry_cache

(btw I'll move it to sysfs)

>> >What about the idea to integrate the inquiry into the library or into
>> >the Bluetooth master daemon.
>> I don't see a need for forwarding inquiry results from a daemon. It can be 
>> done in a simple way in the kernel, just like I explained in prev emails
>> (ie kernel parsing hci_inquiry command).
>
>My concern is the HCI_INQUIRY ioctl, because it don't really fits the
>possibilities and specification details of the inquiry command. 
It should go then :)

>But I don't know what the best way is here and with Bluetooth 1.2 we can also
>get the RSSI from an inquiry result.
>
>At the moment I think additional ioctl's for accessing the inquiry cache
>will make it possible to use the inquiry command in a more dynamic way:
>
>        - get number of inquiry cache entries
>        - copy first n inquiry cache entries to my buffer
>        - flush inquiry cache
>
>Comments? Ideas?
#1 and 2 are already supported in 2.6 (via /proc/.../inquiry_cache).
We could make 'echo 0 > /proc/.../inquiry_cache' flush the cache.

Max