public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.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 05:15:37 +0200	[thread overview]
Message-ID: <1156043737.3989.32.camel@aeonflux.holtmann.net> (raw)
In-Reply-To: <20060820003154.GA17093@srcf.ucam.org>

Hi Matthew,

> > I meant exactly that. The method should work out what information got
> > passed to it. Of course this might not be easy to implement, but that is
> > not the point behind this API. The whole API is designed to make it easy
> > for all kind of applications. And the main focus is not the C language.
> 
> Ok, cool. Now I know what to aim for, I'll head back to that :)

I think a lot of people missed the discussions behind the API since we
did them basically behind closed doors. The main focus will always be
the client application. You really have to think the other way around.

> > I also don't see the problem here. The ASCII service string are a
> > predefined list of names that actually match to specific UUID. Since in
> > the end we will implement all needed service names for all known
> > profiles, we only need to support UUID128. These have a unique form and
> > are kinda easy to detect. If the provided UUID128 matches the Bluetooth
> > base string, then we can internally use UUID32 or UUID16. As simple as
> > that. For the record handles we give them in hex and so they are also
> > easy to identify. And I would check the string in this order.
> 
> Ok, makes sense.

And the weird indentifiers are free formed strings that doesn't match
any of the other categories. And since the server will hand them out it
is an easy requirement to fulfill. These are also not meant to have any
meaning. In general they can be random garbage. The server knows what to
do with them.

You will also see that we love using strings, because in languages like
Python they are so easy to handle. If it is not an integer by definition
we might go with a string as type, because it is more flexible.

Regards

Marcel



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

  reply	other threads:[~2006-08-20  3:15 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
2006-08-20  2:13             ` Marcel Holtmann
2006-08-20  0:31               ` Matthew Garrett
2006-08-20  3:15                 ` Marcel Holtmann [this message]
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=1156043737.3989.32.camel@aeonflux.holtmann.net \
    --to=marcel@holtmann.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