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
next prev parent 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