Hi Stephen,
I've just realised that you didn't keep the UUID and attribute
list of sdptool in sync. The patch below correct this.
Also : I believe that having in the sdp library all the
functions xxx2str() (uuid2str, sdp_proto_uuid2strn...) and their
associated data (struct tupla ServiceClass...) is not
necessary.
Realistically, only sdptool or a graphical equivalent would
use those functions, the vast majority of users of the library would
be like 'pand' and only create or search SDP records.
Moving this functionality to sdptool would allow to reduce
further the size of the SDP library.
Have fun...
Jean
-------------------------------------------------------
--- listattr.s1.c Mon Sep 15 11:59:20 2003
+++ listattr.c Mon Sep 15 14:55:42 2003
@@ -9,7 +9,7 @@
/************************** DOCUMENTATION **************************/
/*
* This code use a "brute force" approach to parsing SDP records.
- * Instead of a top down approach in sdptool, which pick only know
+ * Instead of a top down approach in sdptool, which pick only known
* attributes/members, we use a bottom up approach, printing every
* single bit of the record and trying to associate its defintion
* to it.
@@ -79,20 +79,27 @@ static char *indent_spaces = "
* we need to find what is the service (which is messy) - Jean II */
#define SERVICE_ATTR 0x1
-/* Defintion of the optional arguments in protocol list */
+/* Definition of the optional arguments in protocol list */
static struct member_def protocol_members[] = {
{ "Protocol" },
{ "Channel/Port" },
{ "Version" },
};
-/* Defintion of the optional arguments in profile list */
+/* Definition of the optional arguments in profile list */
static struct member_def profile_members[] = {
{ "Profile" },
{ "Version" },
};
-/* Name of the various attributes. See BT assigned numbers */
+/* Definition of the optional arguments in Language list */
+static struct member_def language_members[] = {
+ { "Code ISO639" },
+ { "Encoding" },
+ { "Base Offset" },
+};
+
+/* Name of the various common attributes. See BT assigned numbers */
static struct attrib_def attrib_names[] = {
{ 0x0, "ServiceRecordHandle", NULL, 0 },
{ 0x1, "ServiceClassIDList", NULL, 0 },
@@ -101,7 +108,8 @@ static struct attrib_def attrib_names[]
{ 0x4, "ProtocolDescriptorList",
protocol_members, sizeof(protocol_members)/sizeof(struct member_def) },
{ 0x5, "BrowseGroupList", NULL, 0 },
- { 0x6, "LanguageBaseAttributeIDList", NULL, 0 },
+ { 0x6, "LanguageBaseAttributeIDList",
+ language_members, sizeof(language_members)/sizeof(struct member_def) },
{ 0x7, "ServiceInfoTimeToLive", NULL, 0 },
{ 0x8, "ServiceAvailability", NULL, 0 },
{ 0x9, "BluetoothProfileDescriptorList",
@@ -126,6 +134,17 @@ static struct attrib_def browse_attrib_n
{ 0x200, "GroupID", NULL, 0 },
};
+/* Name of the various PAN attributes. See BT assigned numbers */
+/* Note : those need to be double checked - Jean II */
+static struct attrib_def pan_attrib_names[] = {
+ { 0x200, "IpSubnet", NULL, 0 }, /* Obsolete ??? */
+ { 0x30A, "SecurityDescription", NULL, 0 },
+ { 0x30B, "NetAccessType", NULL, 0 },
+ { 0x30C, "MaxNetAccessrate", NULL, 0 },
+ { 0x30D, "IPv4Subnet", NULL, 0 },
+ { 0x30E, "IPv6Subnet", NULL, 0 },
+};
+
/* Same for the UUIDs. See BT assigned numbers */
static struct uuid_def uuid16_names[] = {
/* -- Protocols -- */
@@ -165,12 +184,40 @@ static struct uuid_def uuid16_names[] =
{ 0x1105, "OBEXObjectPush", NULL, 0 },
{ 0x1106, "OBEXFileTransfer", NULL, 0 },
{ 0x1107, "IrMCSyncCommand", NULL, 0 },
+ { 0x1108, "Headset", NULL, 0 },
+ { 0x1109, "CordlessTelephony", NULL, 0 },
/* ... */
- { 0x1115, "PANU (PAN/BNEP)", NULL, 0 },
- { 0x1116, "NAP (PAN/BNEP)", NULL, 0 },
- { 0x1117, "GN (PAN/BNEP)", NULL, 0 },
+ { 0x110F, "VideoConferencing", NULL, 0 },
+ { 0x1110, "Intercom", NULL, 0 },
+ { 0x1111, "Fax", NULL, 0 },
+ { 0x1112, "HeadsetAudioGateway", NULL, 0 },
+ { 0x1113, "WAP", NULL, 0 },
+ { 0x1114, "WAP_CLIENT", NULL, 0 },
+ { 0x1115, "PANU (PAN/BNEP)",
+ pan_attrib_names, sizeof(pan_attrib_names)/sizeof(struct attrib_def) },
+ { 0x1116, "NAP (PAN/BNEP)",
+ pan_attrib_names, sizeof(pan_attrib_names)/sizeof(struct attrib_def) },
+ { 0x1117, "GN (PAN/BNEP)",
+ pan_attrib_names, sizeof(pan_attrib_names)/sizeof(struct attrib_def) },
+ { 0x1118, "DirectPrinting (BPP)", NULL, 0 },
+ { 0x1119, "ReferencePrinting (BPP)", NULL, 0 },
/* ... */
+ { 0x1120, "DirectPrintingReferenceObjectsService (BPP)", NULL, 0 },
+ { 0x1121, "ReflectedUI (BPP)", NULL, 0 },
+ { 0x1122, "BasicPrinting (BPP)", NULL, 0 },
+ { 0x1123, "PrintingStatus (BPP)", NULL, 0 },
+ { 0x1124, "HumanInterfaceDeviceService (HID)", NULL, 0 },
+ { 0x1125, "HardcopyCableReplacement (HCR)", NULL, 0 },
+ { 0x1126, "HCR_Print (HCR)", NULL, 0 },
+ { 0x1127, "HCR_Scan (HCR)", NULL, 0 },
{ 0x1128, "Common ISDN Access (CIP)", NULL, 0 },
+ { 0x1129, "VideoConferencingGW (VCP)", NULL, 0 },
+ /* ... */
+ { 0x1200, "PnPInformation", NULL, 0 },
+ { 0x1201, "GenericNetworking", NULL, 0 },
+ { 0x1202, "GenericFileTransfer", NULL, 0 },
+ { 0x1203, "GenericAudio", NULL, 0 },
+ { 0x1204, "GenericTelephony", NULL, 0 },
};
const int uuid16_max = sizeof(uuid16_names)/sizeof(struct uuid_def);
@@ -340,7 +387,6 @@ void sdp_data_printf(sdp_data_t *sdpdata
case SDP_ALT16:
case SDP_ALT32:
printf("%.*sData Sequence Alternates\n", indent, indent_spaces);
- /* Not tested, and I believe it's bogus - Jean II */
printf_dataseq(sdpdata->val.dataseq, context, indent);
break;
}
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fred,
> > > I'm not sure if this question goes in the same direction, but what
> > > happened to the idea of a general purpose rfcomm-inetd, which also sets
> > > up sdp records for its clients? Maybe I'm not really up-to-date, and I
> > > didn't find too much about it in the archives.. is there one already?
> >
> > this makes no sense, because the SDP records are application (or call it
> > profile) specific. And the SDP infos should be coded in the application
> > itself and not in any master daemon.
>
> I already have something like that working, but its a KDE daemon that runs
> under the user account of the current user. An application can specify a sdp
> record as an xml file, leaving the rfcomm channel attribute variable. The
> server looks for a free rfcomm port and sets up the sdp record for each
> application/registration file with the proper rfcomm channel. Of course this
> won't be flexible enough for some applications, but it makes life easier if
> you want a small daemon with a custom profile. Otherwise people are much more
> tempted to hardcode rfcomm channels for small applications.
> I don't see why this shouldn't make any sense, but as long as there is no
> demand it's not worth the effort of course.
you don't got my point, because you are talking about two different
thinks. An inetd like daemon must know of the SDP records when it is
listening on the RFCOMM channels, because it must advertise them first
before another device can detect this service and make use of it. What
you are running is a wrapper for SDP record registration and RFCOMM
listen/accept commands.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wednesday 17 September 2003 01:45, Marcel Holtmann wrote:
> > I'm not sure if this question goes in the same direction, but what
> > happened to the idea of a general purpose rfcomm-inetd, which also sets
> > up sdp records for its clients? Maybe I'm not really up-to-date, and I
> > didn't find too much about it in the archives.. is there one already?
>
> this makes no sense, because the SDP records are application (or call it
> profile) specific. And the SDP infos should be coded in the application
> itself and not in any master daemon.
I already have something like that working, but its a KDE daemon that runs
under the user account of the current user. An application can specify a sdp
record as an xml file, leaving the rfcomm channel attribute variable. The
server looks for a free rfcomm port and sets up the sdp record for each
application/registration file with the proper rfcomm channel. Of course this
won't be flexible enough for some applications, but it makes life easier if
you want a small daemon with a custom profile. Otherwise people are much more
tempted to hardcode rfcomm channels for small applications.
I don't see why this shouldn't make any sense, but as long as there is no
demand it's not worth the effort of course.
regards
Fred
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2003-09-17 at 01:49 +0200, Marcel Holtmann wrote:
> Hi David,
>
> > Feature request: Please can we make sdpd retain its knowledge of apps
> > which have registered with it over a restart, much like portmap does?
>
> actually I don't know how we can do this, but I put a note on my feature
> list for the new SDP server.
I don't know either -- but portmap does seem to get it right.
--
dwmw2
Hi Jean,
> > I forgot to mention that I started from scratch and the output you see
> > above is a textual presentation of the new internal data structure. The
> > core attributes id's and the UUID16's are decoded into strings, because
> > they are unique. All other meanings of some data elements depends on
> > others. I have to add some checks which makes sure that this is a valid
> > SDP record, before I can do this.
>
> Well... What was wrong with the code I wrote in listattr.c ?
> It did all of that properly and simply, and it was trivial to add new
> UUIDs and attributes. I don't see what you have gained here...
there was nothing wrong with that code and I think my final code for
that part will look very similar. My problem is the current API itself,
because it is a mess and if you have to do more complicated things with
SDP you are simply lost.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, Sep 17, 2003 at 02:28:15AM +0200, Marcel Holtmann wrote:
> Hi Jean,
>
> I forgot to mention that I started from scratch and the output you see
> above is a textual presentation of the new internal data structure. The
> core attributes id's and the UUID16's are decoded into strings, because
> they are unique. All other meanings of some data elements depends on
> others. I have to add some checks which makes sure that this is a valid
> SDP record, before I can do this.
Well... What was wrong with the code I wrote in listattr.c ?
It did all of that properly and simply, and it was trivial to add new
UUIDs and attributes. I don't see what you have gained here...
> Regards
>
> Marcel
Jean
Hi Jean,
> > who are the current users of sdp_uuid_cmp() ?
>
> As far as I can see, it's only used internally, like this :
>
> record.c: if (sdp_list_find(rec->pattern, uuid128, sdp_uuid_cmp) == NULL)
> record.c: rec->pattern = sdp_list_insert_sorted(rec->pattern, uuid128, sdp_uuid_cmp);
>
> I believe that it can only work with the server records,
> because it require all UUIDs to be 128, whereas the UUID you get as a
> client are UUID16. That's why I needed the other function :
>
> if(sdp_list_find(services, &service_nap, sdp_uuid16_cmp) != NULL)
please send me a patch, with the modified code above, your function name
change and the extra function.
> > Of course, because that is the only output that matters to me and I
> > don't find the tree output so ugly. This is an example output of my
> > Bluespoon headset from my code:
> >
> > Sequence
> > Attribute 0x0000 - Service record handle
> > UINT32 0x00010000
> > Attribute 0x0001 - Service class ID list
> > Sequence
> > UUID16 0x1108 - Headset
> > UUID16 0x1203 - Generic Audio
> > Attribute 0x0004 - Protocol descriptor list
> > Sequence
> > Sequence
> > UUID16 0x0100 - L2CAP
> > Sequence
> > UUID16 0x0003 - RFCOMM
>
> This looks much better than what I have with sdp-1.2, it seems
> that you have done some nice cleanup. Wonderful ;-)
>
> > UINT8 0x01
>
> Why is this one broken ? In version 1.2, it should display
> "Channel/Port".
>
> > Attribute 0x0009 - Bluetooth profile descriptor list
> > Sequence
> > Sequence
> > UUID16 0x1108 - Headset
> > UINT16 0x0100
>
> I can't help on this one, but that would be easy to add.
>
> > Attribute 0x0302
> > Bool True
I forgot to mention that I started from scratch and the output you see
above is a textual presentation of the new internal data structure. The
core attributes id's and the UUID16's are decoded into strings, because
they are unique. All other meanings of some data elements depends on
others. I have to add some checks which makes sure that this is a valid
SDP record, before I can do this.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, Sep 17, 2003 at 01:42:27AM +0200, Marcel Holtmann wrote:
> Hi Jean,
>
> > While you are at it, would you mid to do the following :
> > o rename sdp_uuid_cmp() to sdp_uuid128_cmp(). The current name
> > totally confused me.
>
> who are the current users of sdp_uuid_cmp() ?
As far as I can see, it's only used internally, like this :
record.c: if (sdp_list_find(rec->pattern, uuid128, sdp_uuid_cmp) == NULL)
record.c: rec->pattern = sdp_list_insert_sorted(rec->pattern, uuid128, sdp_uuid_cmp);
I believe that it can only work with the server records,
because it require all UUIDs to be 128, whereas the UUID you get as a
client are UUID16. That's why I needed the other function :
if(sdp_list_find(services, &service_nap, sdp_uuid16_cmp) != NULL)
> > I hope you will keep the --tree browsing option in sdptool,
> > because the default browsing is useless for advanced stuff. The
> > display might be ugly, but at least it display everything and the
> > basic infrastructure is sound.
>
> Of course, because that is the only output that matters to me and I
> don't find the tree output so ugly. This is an example output of my
> Bluespoon headset from my code:
>
> Sequence
> Attribute 0x0000 - Service record handle
> UINT32 0x00010000
> Attribute 0x0001 - Service class ID list
> Sequence
> UUID16 0x1108 - Headset
> UUID16 0x1203 - Generic Audio
> Attribute 0x0004 - Protocol descriptor list
> Sequence
> Sequence
> UUID16 0x0100 - L2CAP
> Sequence
> UUID16 0x0003 - RFCOMM
This looks much better than what I have with sdp-1.2, it seems
that you have done some nice cleanup. Wonderful ;-)
> UINT8 0x01
Why is this one broken ? In version 1.2, it should display
"Channel/Port".
> Attribute 0x0009 - Bluetooth profile descriptor list
> Sequence
> Sequence
> UUID16 0x1108 - Headset
> UINT16 0x0100
I can't help on this one, but that would be easy to add.
> Attribute 0x0302
> Bool True
Totally untested patch :
---------------------------------------------
--- listattr.s2.c Tue Sep 16 16:53:01 2003
+++ listattr.c Tue Sep 16 17:00:33 2003
@@ -145,6 +145,12 @@ static struct attrib_def pan_attrib_name
{ 0x30E, "IPv6Subnet", NULL, 0 },
};
+/* Name of the various Generic-Audio attributes. See BT assigned numbers */
+/* Note : totally untested - Jean II */
+static struct attrib_def audio_attrib_names[] = {
+ { 0x302, "Remote audio volume control", NULL, 0 },
+};
+
/* Same for the UUIDs. See BT assigned numbers */
static struct uuid_def uuid16_names[] = {
/* -- Protocols -- */
@@ -184,7 +190,8 @@ static struct uuid_def uuid16_names[] =
{ 0x1105, "OBEXObjectPush", NULL, 0 },
{ 0x1106, "OBEXFileTransfer", NULL, 0 },
{ 0x1107, "IrMCSyncCommand", NULL, 0 },
- { 0x1108, "Headset", NULL, 0 },
+ { 0x1108, "Headset",
+ audio_attrib_names, sizeof(audio_attrib_names)/sizeof(struct attrib_def) },
{ 0x1109, "CordlessTelephony", NULL, 0 },
/* ... */
{ 0x110F, "VideoConferencing", NULL, 0 },
@@ -216,7 +223,8 @@ static struct uuid_def uuid16_names[] =
{ 0x1200, "PnPInformation", NULL, 0 },
{ 0x1201, "GenericNetworking", NULL, 0 },
{ 0x1202, "GenericFileTransfer", NULL, 0 },
- { 0x1203, "GenericAudio", NULL, 0 },
+ { 0x1203, "GenericAudio",
+ audio_attrib_names, sizeof(audio_attrib_names)/sizeof(struct attrib_def) },
{ 0x1204, "GenericTelephony", NULL, 0 },
};
---------------------------------------------
> Regards
>
> Marcel
Have fun...
Jean
Hi David,
> Feature request: Please can we make sdpd retain its knowledge of apps
> which have registered with it over a restart, much like portmap does?
actually I don't know how we can do this, but I put a note on my feature
list for the new SDP server.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fred,
> I'm not sure if this question goes in the same direction, but what happened to
> the idea of a general purpose rfcomm-inetd, which also sets up sdp records
> for its clients? Maybe I'm not really up-to-date, and I didn't find too much
> about it in the archives.. is there one already?
this makes no sense, because the SDP records are application (or call it
profile) specific. And the SDP infos should be coded in the application
itself and not in any master daemon.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Jean,
> While you are at it, would you mid to do the following :
> o rename sdp_uuid_cmp() to sdp_uuid128_cmp(). The current name
> totally confused me.
who are the current users of sdp_uuid_cmp() ?
> Or make it two libraries.
The goal is to have only one Bluetooth library. But we care about the
embedded people, so comments are welcome.
> I hope you will keep the --tree browsing option in sdptool,
> because the default browsing is useless for advanced stuff. The
> display might be ugly, but at least it display everything and the
> basic infrastructure is sound.
Of course, because that is the only output that matters to me and I
don't find the tree output so ugly. This is an example output of my
Bluespoon headset from my code:
Sequence
Attribute 0x0000 - Service record handle
UINT32 0x00010000
Attribute 0x0001 - Service class ID list
Sequence
UUID16 0x1108 - Headset
UUID16 0x1203 - Generic Audio
Attribute 0x0004 - Protocol descriptor list
Sequence
Sequence
UUID16 0x0100 - L2CAP
Sequence
UUID16 0x0003 - RFCOMM
UINT8 0x01
Attribute 0x0009 - Bluetooth profile descriptor list
Sequence
Sequence
UUID16 0x1108 - Headset
UINT16 0x0100
Attribute 0x0100
String Headset
Attribute 0x0302
Bool True
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, Sep 16, 2003 at 01:33:20PM +0200, Marcel Holtmann wrote:
> Hi Jean,
>
> > I've just realised that you didn't keep the UUID and attribute
> > list of sdptool in sync. The patch below correct this.
>
> I have applied your patch, thanks.
While you are at it, would you mid to do the following :
o rename sdp_uuid_cmp() to sdp_uuid128_cmp(). The current name
totally confused me.
o add in the library the following function :
------------------------------------------------
/*
* UUID comparison function
* returns 0 if uuidValue1 == uuidValue2 else -1
*/
int sdp_uuid16_cmp(const void *p1, const void *p2)
{
const uuid_t *u1 = (const uuid_t *)p1;
const uuid_t *u2 = (const uuid_t *)p2;
return memcmp(&u1->value.uuid16, &u2->value.uuid16, sizeof(uint16_t));
}
------------------------------------------------
> > Also : I believe that having in the sdp library all the
> > functions xxx2str() (uuid2str, sdp_proto_uuid2strn...) and their
> > associated data (struct tupla ServiceClass...) is not
> > necessary.
> > Realistically, only sdptool or a graphical equivalent would
> > use those functions, the vast majority of users of the library would
> > be like 'pand' and only create or search SDP records.
> > Moving this functionality to sdptool would allow to reduce
> > further the size of the SDP library.
>
> I like to keep this functions in the library, because they are a good
> for debugging and they can be shared between any graphical and terminal
> SDP tools. Anyway it seems to me like a good idea to have a compile
> switch to disable the string arrays and let the functions return NULL
> instead. People which care about the library size can use it.
Or make it two libraries.
> My work on the 4th (or maybe 5th) generation of a SDP library is making
> good progress and I hope that I will have clean code for publishing very
> soon.
I hope you will keep the --tree browsing option in sdptool,
because the default browsing is useless for advanced stuff. The
display might be ugly, but at least it display everything and the
basic infrastructure is sound.
> Regards
>
> Marcel
Have fun...
Jean
On Tuesday 16 September 2003 15:03, David Woodhouse wrote:
..
> Feature request: Please can we make sdpd retain its knowledge of apps
> which have registered with it over a restart, much like portmap does?
I'm not sure if this question goes in the same direction, but what happened to
the idea of a general purpose rfcomm-inetd, which also sets up sdp records
for its clients? Maybe I'm not really up-to-date, and I didn't find too much
about it in the archives.. is there one already?
Fred
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 2003-09-16 at 13:33 +0200, Marcel Holtmann wrote:
> My work on the 4th (or maybe 5th) generation of a SDP library is making
> good progress and I hope that I will have clean code for publishing very
> soon.
Feature request: Please can we make sdpd retain its knowledge of apps
which have registered with it over a restart, much like portmap does?
--
dwmw2
Hi Jean,
> I've just realised that you didn't keep the UUID and attribute
> list of sdptool in sync. The patch below correct this.
I have applied your patch, thanks.
> Also : I believe that having in the sdp library all the
> functions xxx2str() (uuid2str, sdp_proto_uuid2strn...) and their
> associated data (struct tupla ServiceClass...) is not
> necessary.
> Realistically, only sdptool or a graphical equivalent would
> use those functions, the vast majority of users of the library would
> be like 'pand' and only create or search SDP records.
> Moving this functionality to sdptool would allow to reduce
> further the size of the SDP library.
I like to keep this functions in the library, because they are a good
for debugging and they can be shared between any graphical and terminal
SDP tools. Anyway it seems to me like a good idea to have a compile
switch to disable the string arrays and let the functions return NULL
instead. People which care about the library size can use it.
My work on the 4th (or maybe 5th) generation of a SDP library is making
good progress and I hope that I will have clean code for publishing very
soon.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel