From: Matthew Garrett <mjg59@srcf.ucam.org>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] [PATCH] implement RFCOMM Connect and Disconnect methods
Date: Sun, 20 Aug 2006 00:53:30 +0100 [thread overview]
Message-ID: <20060819235330.GA16375@srcf.ucam.org> (raw)
In-Reply-To: <1156037973.3989.14.camel@aeonflux.holtmann.net>
On Sun, Aug 20, 2006 at 03:39:33AM +0200, Marcel Holtmann wrote:
> thanks for the patch, but what is the problem with sticking to Connect
> and CancelConnect and use their service string to identify UUID, handle
> or service name bases connections.
I'm not quite clear on what you mean here. The service string seems
unacceptable because it requires bluez to have a table of every possible
service and UUID in existence. Or are we talking about different things?
Right now, the API gives us the following things that potentially
identify an object:
1) The identifiers returned by GetIdentifiers (currently an arbitrary
but unique integer, despite dbus-api.txt claiming it returns strings)
2) The UUID
3) The service handle
4) The ascii service string
My implementation provides connect methods for (2), (3) and (4). You
didn't seem too happy about my patch providing support for (1), so I've
dropped it :) Or do you just mean that there should be a single method
and it should work out which piece of information has been passed by the
app? In that case, I didn't implement it that way because determining
the type was a bit of a pain and struck me as potentially fragile.
--
Matthew Garrett | mjg59@srcf.ucam.org
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2006-08-19 23:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-17 10:06 [Bluez-devel] [PATCH] implement RFCOMM Connect and Disconnect methods Matthew Garrett
2006-08-17 13:04 ` Marcel Holtmann
2006-08-17 11:41 ` Matthew Garrett
2006-08-17 11:59 ` Johan Hedberg
2006-08-17 12:01 ` Matthew Garrett
2006-08-19 14:36 ` Matthew Garrett
2006-08-20 1:39 ` Marcel Holtmann
2006-08-19 23:53 ` Matthew Garrett [this message]
2006-08-20 2:13 ` Marcel Holtmann
2006-08-20 0:31 ` Matthew Garrett
2006-08-20 3:15 ` Marcel Holtmann
2006-08-20 17:59 ` Matthew Garrett
2006-08-23 6:21 ` [Bluez-devel] RFComm auth/encrypt Denis KENZIOR
2006-08-23 20:13 ` [Bluez-devel] [PATCH] implement RFCOMM Connect and Disconnect methods 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=20060819235330.GA16375@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--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