Linux bluetooth development
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@rvs.uni-bielefeld.de>
To: Max Krasnyansky <maxk@qualcomm.com>
Cc: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] New SDP client library
Date: 09 Oct 2003 18:06:50 +0200	[thread overview]
Message-ID: <1065715616.14514.44.camel@pegasus> (raw)
In-Reply-To: <5.1.0.14.2.20031008172506.020cef30@unixmail.qualcomm.com>

Hi Max,

> >in the last two months I have done much work with the current SDP
> >implementation. The library is full featured and works fine for me in
> >all situations, but the programming interface is a mess. It is not easy
> >to get the service name or the number of the RFCOMM channel. You have to
> >play with internal SDP lists, pointer of pointer stuff and static
> >assigned UUID's. Since I already have rewritten most of the HCI part
> >from scratch for the new Bluetooth library,
> Hmm, what do you mean by that ? As far as I can (in CVS) core functions 
> like hci_open(), hci_send_request(), etc are the same. 

I started with an empty hci.c file and begin looking at the old library.
And of course most functions will be the same, because they are simple,
correct and worked fine for over two years now. The hci_types.h file
will be more amazing ;)

> >The simple interface will have of course a lot of limitations, but these
> >can all be eliminated by using the full interface if needed. I tested
> >the new version with all my devices on my desktop and it works flawless.
> Cool.

Not so cool as I thought in the first place :( While working with the
new library and testing them on other profiles like BIP, HID and HCRP
for example, things are getting worse again. It is hard to see the
complete picture of SDP.

> >I will now clean up the internal stuff a little bit and then place it
> >into the libs2 CVS instead of the "old" one. Comments?
> Looks good to me. We've been talking about simplifying SDP library
> for quite a while. And I completely support the idea.

The current CVS misses some more macros I have already coded, but not
yet commited. They will make the work with SDP much easier. In the case
of BIP, HID and HCRP we really need good SDP support.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2003-10-09 16:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-25 11:29 [Bluez-devel] New SDP client library Marcel Holtmann
2003-10-09  0:35 ` Max Krasnyansky
2003-10-09 16:06   ` Marcel Holtmann [this message]
2003-10-09 17:31     ` Max Krasnyansky
2003-10-09 18:02       ` Marcel Holtmann

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=1065715616.14514.44.camel@pegasus \
    --to=marcel@rvs.uni-bielefeld.de \
    --cc=bluez-devel@lists.sourceforge.net \
    --cc=maxk@qualcomm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox