From: Marcel Holtmann <marcel@rvs.uni-bielefeld.de>
To: Max Krasnyansky <maxk@qualcomm.com>
Cc: Stephen Crane <steve.crane@rococosoft.com>,
Philip Blundell <pb@nexus.co.uk>,
BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Re: Version 3 libs/utils
Date: 22 Jul 2003 12:40:48 +0200 [thread overview]
Message-ID: <1058870455.24408.66.camel@pegasus> (raw)
In-Reply-To: <5.1.0.14.2.20030721173324.096d96b0@unixmail.qualcomm.com>
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
next prev parent reply other threads:[~2003-07-22 10:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-01 0:03 Version 3 libs/utils Max Krasnyansky
2003-07-02 1:01 ` [Bluez-devel] " Marcel Holtmann
2003-07-02 8:34 ` Stephen Crane
2003-07-02 16:29 ` [Bluez-devel] " Marcel Holtmann
2003-07-18 0:19 ` Max Krasnyansky
2003-07-18 0:10 ` Max Krasnyansky
2003-07-18 0:33 ` [Bluez-devel] " Marcel Holtmann
2003-07-22 0:32 ` Max Krasnyansky
2003-07-22 10:06 ` Marcel Holtmann
2003-07-18 0:00 ` Max Krasnyansky
2003-07-18 0:51 ` [Bluez-devel] " Marcel Holtmann
2003-07-22 0:44 ` Max Krasnyansky
2003-07-22 10:40 ` Marcel Holtmann [this message]
2003-07-22 20:05 ` Max Krasnyansky
2003-07-22 21:33 ` Marcel Holtmann
2003-07-23 16:27 ` Max Krasnyansky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1058870455.24408.66.camel@pegasus \
--to=marcel@rvs.uni-bielefeld.de \
--cc=bluez-devel@lists.sourceforge.net \
--cc=maxk@qualcomm.com \
--cc=pb@nexus.co.uk \
--cc=steve.crane@rococosoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.