From: Robert Rawlins <robert_rawlins@hotmail.com>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Moving towards a new API for BlueZ 4.0
Date: Fri, 14 Mar 2008 14:20:49 +0000 [thread overview]
Message-ID: <BAY102-W836C1CD8A589599577B91F00A0@phx.gbl> (raw)
In-Reply-To: <63E1C59E-6425-4B25-B5F2-44CF0107BADD@holtmann.org>
[-- Attachment #1.1: Type: text/plain, Size: 1587 bytes --]
Hi Marcel,
> I am not sure. The code to make this all work is so complicated that I > really wanna remove it when we hit 4.0. Ping me again at some point. > For now we are going without allowing discovery without resolving the > name.
I can imagine this must be a difficult decision to be making, I can appreciate that you want to keep the API and its supporting code as clean as possible.
However, I'm going to +1 with Manuel on this one, my business requirements mean that discovery speed is quite important for me, in fact, I would probably say it was 'vital'. I can appreciate from your stand point that many developers working on gnome bluetooth and dealing with a small number of remote devices it might not be such an issue, however, I think that in a commercial or industrial environment when dealing with M2M communications, knowing the name of a device is pretty insignificant compared to the desire to discover devices efficiently.
It would be a shame to see this feature dropped from the 4.0 build as it would likely mean I am unable to upgrade, I'm also quite sure many other developers working in the industrial sector with M2M and suchlike, such as Manuel, would also be forced into using legacy builds of the stack.
On the flip side, all the other changes to the API look EXCELLENT! I'm looking forward to working with it to see exactly how it implements.
Thanks Marcel,
Robert
_________________________________________________________________
Who's friends with who and co-starred in what?
http://www.searchgamesbox.com/celebrityseparation.shtml
[-- Attachment #1.2: Type: text/html, Size: 1869 bytes --]
[-- Attachment #2: Type: text/plain, Size: 228 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
[-- Attachment #3: Type: text/plain, Size: 164 bytes --]
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2008-03-14 14:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-13 20:32 [Bluez-devel] Moving towards a new API for BlueZ 4.0 Marcel Holtmann
2008-03-14 10:23 ` Manuel Naranjo
2008-03-14 12:23 ` Marcel Holtmann
2008-03-14 13:44 ` Manuel Naranjo
2008-03-14 14:00 ` Marcel Holtmann
2008-03-14 14:15 ` Manuel Naranjo
2008-03-14 14:20 ` Robert Rawlins [this message]
2008-03-19 23:04 ` David Stockwell
2008-03-20 13:50 ` Marcel Holtmann
2008-03-20 14:49 ` Johan Hedberg
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=BAY102-W836C1CD8A589599577B91F00A0@phx.gbl \
--to=robert_rawlins@hotmail.com \
--cc=bluez-devel@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox