public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: "Claudio Takahasi" <cktakahasi@gmail.com>
To: "BlueZ development" <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Proposed DTD
Date: Fri, 10 Nov 2006 18:38:06 -0300	[thread overview]
Message-ID: <e1effdeb0611101338v1902b247if13f2239622f1a3a@mail.gmail.com> (raw)
In-Reply-To: <e1effdeb0611101009t24de879fk3bca7ed96821514e@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4076 bytes --]

On 11/10/06, Claudio Takahasi <cktakahasi@gmail.com> wrote:
> On 11/8/06, Denis KENZIOR <denis.kenzior@trolltech.com> wrote:
> > Marcel,
> >
> > On Monday 30 October 2006 23:27, Marcel Holtmann wrote:
> > > Hi Denis,
> > >
> > >
> > > to get this started, I like to see the method
> > >
> > > string GetRemoteServiceRecordAsXML(string address, uint32 handle)
> > >
> > > from the org.bluez.Adapter interface gets implemented and make it using
> > > the simple service-record.dtd I put into the CVS.
> >
> > Here's a patch that imlements
> >
> > string GetRemoteServiceRecordAsXML(string address, uint32 handle)
> >
> > >
> > > I choose to simplify the DTD a lot. After having a discussion about XML
> >
> > Yes, I saw this.  I have made some changes to the DTD however.  Mainly I've
> > added the int* data types and have removed the 'data' type since it was not
> > used anywhere anymore.
> >
> > > and binary representation from the SDP part of the specification, I am
> > > pretty certain, that we should support both. The binary representation
> > > will cover all tasks ever possible with SDP and it is the default. For
> > > convenience we will additionally support XML as record description, but
> > > it will only cover up to 90% of all cases, but it will be simpler to use
> > > and easier to understand and that should be fine.
> > >
> >
> > I'm concerned about this.  BlueZ dbus developers have explicitly and
> > repeatedly stated that their intent is to make the dbus interface as
> > high-level as possible.  This is why the interface is so nice and easy to
> > use, particularly from languages other than C.  Binary SDP record
> > representation/registration just does not fit.  I would strongly encourage
> > that we adopt an XML format for both view and registration of SDP records,
> > and that it should be the default.
> >
> > There's also the issue of GPL.  Anybody who wants to create such binary
> > records and cannot link against the GPL'd libbluetooth would need to spend
> > (perhaps considerable) time duplicating what is already there in order to
> > produce such data structures.
> >
> > > This means that all length fields are not represented in XML. They will
> > > be chosen automatically as needed. The same applies to the UUID. So it
> > > leaves only int* and uint* where the actual size will be taken care of
> > > as part of the type name.
> >
> > I totally agree with this and this was my original thought as well.  Hopefully
> > the dtd is getting closer to being finalized.  This reminds me, do you still
> > want to base sdptool on XML if an appropriate (no external dependency) parser
> > is written?  I don't want to spend time on this unless it is wanted and the
> > DTD is stabilized.
> >
> > Regards,
> > Denis
> >
> >
> > -------------------------------------------------------------------------
> > 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
> >
> >
> >
> >
>
> Hi Denis,
>
> the patch is in cvs now!
>
> The sdp-xml.* were moved to common directory.
>
> Some points to be improved:
> 1. append_and_grow_string: avoid a lot of strlen calls and string copy
> 2. Analyze if it is possible use sdp_buf_t instead of string_t
> 3. I got some system bus disconnection messages when calling
> GetRemoteServiceRecordAsXML consecutively. We need fix this bug.
>
> BR,
> Claudio.
> --

Hi Marcel, Denis,

this patch replaces string_t by sdp_buf_t and fix system bus
disconnection problem. Check if this patch make sense or if it is
better keep  string_t.

BR,
Claudio
-- 
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT

[-- Attachment #2: remove_string_t.patch --]
[-- Type: text/x-patch, Size: 2532 bytes --]

Index: hcid/dbus-sdp.c
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-sdp.c,v
retrieving revision 1.55
diff -u -r1.55 dbus-sdp.c
--- hcid/dbus-sdp.c	10 Nov 2006 17:59:15 -0000	1.55
+++ hcid/dbus-sdp.c	10 Nov 2006 21:21:03 -0000
@@ -58,7 +58,6 @@
 #include "sdp-xml.h"
 
 #define MAX_IDENTIFIER_LEN	29	/* "XX:XX:XX:XX:XX:XX/0xYYYYYYYY\0" */
-#define DEFAULT_XML_BUFFER_SIZE 1024
 
 struct service_provider {
 	char *owner;	/* null for remote services or unique name if local */
@@ -100,31 +99,26 @@
 	char            *info_name;
 } sdp_service_t;
 
-typedef struct {
-	int size;
-	char *str;
-} string_t;
-
 static void append_and_grow_string(void *data, const char *str)
 {
-	string_t *string = (string_t *)data;
-	char *newbuf;
+	sdp_buf_t *buff = (sdp_buf_t *) data;
+	int len;
 
-	int oldlen = strlen(string->str);
-	int newlen = strlen(str);
-	
-	if ((oldlen + newlen + 1) > string->size) {
-		newbuf = (char *) malloc(string->size * 2);
-		if (!newbuf)
-			return;
+	len = strlen(str);
 
-		memcpy(newbuf, string->str, oldlen+1);
-		string->size *= 2;
-		free(string->str);
-		string->str = newbuf;		
+	if (buff->buf_size < (buff->data_size + len + 1)) {
+		if (!buff->buf_size)
+			buff->buf_size = 1;
+
+		buff->buf_size += len;
+		buff->data = realloc(buff->data, buff->buf_size);
+		if (!buff->data)
+			return;
 	}
 
-	strcat(string->str, str);
+	/* Include the NULL character */
+	memcpy(buff->data + buff->data_size, str, len + 1);
+	buff->data_size += len;
 }
 
 /* FIXME:  move to a common file */
@@ -648,8 +642,8 @@
 	DBusMessage *reply;
 	const char *dst;
 	int scanned;
-	string_t result;
-	
+	sdp_buf_t result;
+
 	if (!ctxt)
 		return;
 
@@ -685,7 +679,6 @@
 
 	reply = dbus_message_new_method_return(ctxt->rq);
 
-	result.str = 0;
 	
 	rec = sdp_extract_pdu(rsp, &scanned);
 	if (rec == NULL) {
@@ -693,20 +686,21 @@
 		goto done;
 	}
 
-	result.str = malloc(sizeof(char) * DEFAULT_XML_BUFFER_SIZE);
-	result.size = DEFAULT_XML_BUFFER_SIZE;
-	
+	memset(&result, 0, sizeof(sdp_buf_t));
+
 	sdp_cache_append(NULL, dst, rec);
 
 	convert_sdp_record_to_xml(rec, &result, append_and_grow_string);
 
-	dbus_message_append_args(reply,
-		DBUS_TYPE_STRING, &result.str,
-		DBUS_TYPE_INVALID);
+	if (result.data) {
+		dbus_message_append_args(reply,
+				DBUS_TYPE_STRING, &result.data,
+				DBUS_TYPE_INVALID);
 
+		free(result.data);
+	}
 done:
 	send_message_and_unref(ctxt->conn, reply);
-	free(result.str);
 failed:
 	transaction_context_free(ctxt);
 }

[-- Attachment #3: Type: text/plain, Size: 373 bytes --]

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

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2006-11-10 21:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-23  0:25 [Bluez-devel] Proposed DTD Denis KENZIOR
2006-10-23  3:13 ` Marcel Holtmann
2006-10-23  3:59   ` Denis KENZIOR
2006-10-23  4:11     ` Marcel Holtmann
2006-10-23  4:31       ` Denis KENZIOR
2006-10-23  7:27         ` Marcel Holtmann
2006-10-24  5:47           ` Denis KENZIOR
2006-10-24  8:13             ` Marcel Holtmann
2006-10-24  6:47               ` Denis KENZIOR
2006-10-24  9:16                 ` Marcel Holtmann
2006-10-24  8:09                   ` Denis KENZIOR
2006-10-24 10:17                     ` Marcel Holtmann
2006-10-30 13:27                 ` Marcel Holtmann
2006-11-09  1:49                   ` Denis KENZIOR
2006-11-10 18:09                     ` Claudio Takahasi
2006-11-10 21:38                       ` Claudio Takahasi [this message]
2006-11-13  1:14                         ` Denis KENZIOR
2006-11-13  6:21                           ` Marcel Holtmann
2006-11-13  6:37                     ` Marcel Holtmann
2006-11-13  7:03                       ` Denis KENZIOR
2006-11-13  7:17                         ` Marcel Holtmann
2006-10-24  7:08               ` Denis KENZIOR
2006-10-24  9:13                 ` 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=e1effdeb0611101338v1902b247if13f2239622f1a3a@mail.gmail.com \
    --to=cktakahasi@gmail.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