_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> > Can also provide an example XML record for a really simple serial port
> > profile. This will help to see how it looks like.
> >
> > Anyone willing to write a really specific and simple XML parser to
> > convert these XML files into sdp_record_t structures. And or course a
> > function that converts this structure back to XML.
>
> Attached is a sample of OPUSH profile. Attached also is the code to generate
> one of these and parse one of these as well (you can use attached sdptool
> patch to play with it)
>
> The code is still pretty raw, but it should at least get us started.
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.
I choose to simplify the DTD a lot. After having a discussion about XML
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.
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.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> > > Yes, the encoding is only relevant for the <text[8,16,32]> fields. The
> > > rest of the attributes should not have it (this is hard to express in a
> > > DTD.)
> >
> > then don't express it at all. Leave it out. An XML file can be valid
> > based on its DTD, but still be rejected when stuff is not passing the
> > semantic requirements.
I prefer to leave it out now and then add it later if really needed. It
is simpler to add something than to remove it.
> I'd rather leave it, encoding attribute is optional anyway, and as you said
> it'll only happen for HID profile. Might as well treat the entire thing as a
> data blob.
>
> > If I can get an XML parser that only deals with this specific DTD and is
> > not using expat at all, I am willing to include it right away and make
> > sdptool use it.
>
> Cool. I will be unable to work on this for a few weeks, so if nobody steps up
> till then I'll see what I can do. In the interest of getting something
> working quickly and generating feedback, would you be willing to introduce a
> dependency on expat for hcid? The XML infrastructure really belongs in the
> new dbus API anyway.
Having a temporary expat dependency is not an option am willing to go
for. However removing the code from sdptool and only put some XML
templates in a shared place seems like a good option.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
> > Yes, the encoding is only relevant for the <text[8,16,32]> fields. The
> > rest of the attributes should not have it (this is hard to express in a
> > DTD.)
>
> then don't express it at all. Leave it out. An XML file can be valid
> based on its DTD, but still be rejected when stuff is not passing the
> semantic requirements.
I'd rather leave it, encoding attribute is optional anyway, and as you said
it'll only happen for HID profile. Might as well treat the entire thing as a
data blob.
> If I can get an XML parser that only deals with this specific DTD and is
> not using expat at all, I am willing to include it right away and make
> sdptool use it.
Cool. I will be unable to work on this for a few weeks, so if nobody steps up
till then I'll see what I can do. In the interest of getting something
working quickly and generating feedback, would you be willing to introduce a
dependency on expat for hcid? The XML infrastructure really belongs in the
new dbus API anyway.
-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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> > > Based on your feedback a new DTD specification. Hopefully it is getting
> > > closer.
> >
> > looks good. However the text about hex encoded is not needed. All number
> > based values can be either in hex or decimal or whatever. We will use
> > the standard encoding to detect it. For example if it starts with 0x
> > then it is hex, otherwise it is decimal.
>
> Yes, the encoding is only relevant for the <text[8,16,32]> fields. The rest
> of the attributes should not have it (this is hard to express in a DTD.)
then don't express it at all. Leave it out. An XML file can be valid
based on its DTD, but still be rejected when stuff is not passing the
semantic requirements.
> > I am also not sure that the encoding attribute is needed. If you wanna
> > encode binary data in text elements (at the moment only HID does this)
> > then you can use \000 style encoding to do so.
>
> This does not seem to be supported by expat, unless I'm missing something. I
> also want to expand encoding to eventually have a base64 option, for space
> saving.
>
> How would this work, do you mean to just recognize if a character starts with
> \0xxx - Octal
> \xx - Hex?
Use the same logic as printf() is using for example.
> > Can also provide an example XML record for a really simple serial port
> > profile. This will help to see how it looks like.
> >
> > Anyone willing to write a really specific and simple XML parser to
> > convert these XML files into sdp_record_t structures. And or course a
> > function that converts this structure back to XML.
>
> Attached is a sample of OPUSH profile. Attached also is the code to generate
> one of these and parse one of these as well (you can use attached sdptool
> patch to play with it)
>
> The code is still pretty raw, but it should at least get us started.
If I can get an XML parser that only deals with this specific DTD and is
not using expat at all, I am willing to include it right away and make
sdptool use it.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> > I am also not sure that the encoding attribute is needed. If you wanna
> > encode binary data in text elements (at the moment only HID does this)
> > then you can use \000 style encoding to do so.
>
> Perhaps you mean the '�' style escapes? This is feasible, except that
> expat assumes attributes do not contain raw data (it returns an array of
> const char * and assumes it is null terminated). Thus we would need to
> switch text* (and perhaps url*?) elements to be something like:
>
> <!ELEMENT text (#PCDATA)>
>
> or find another parser.
we do the parsing of the string by ourself. You only have to do that for
binary strings anyway. And they are expected only in the HID profile so
far. So that shouldn't be that big problem.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
> I am also not sure that the encoding attribute is needed. If you wanna
> encode binary data in text elements (at the moment only HID does this)
> then you can use \000 style encoding to do so.
Perhaps you mean the '�' style escapes? This is feasible, except that
expat assumes attributes do not contain raw data (it returns an array of
const char * and assumes it is null terminated). Thus we would need to
switch text* (and perhaps url*?) elements to be something like:
<!ELEMENT text (#PCDATA)>
or find another parser.
-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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> Based on your feedback a new DTD specification. Hopefully it is getting
> closer.
looks good. However the text about hex encoded is not needed. All number
based values can be either in hex or decimal or whatever. We will use
the standard encoding to detect it. For example if it starts with 0x
then it is hex, otherwise it is decimal.
I am also not sure that the encoding attribute is needed. If you wanna
encode binary data in text elements (at the moment only HID does this)
then you can use \000 style encoding to do so.
Can also provide an example XML record for a really simple serial port
profile. This will help to see how it looks like.
Anyone willing to write a really specific and simple XML parser to
convert these XML files into sdp_record_t structures. And or course a
function that converts this structure back to XML.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> > > I can see your point on being lower case, so this is something I agree
> > > with.
> > >
> > > I don't really like using the single data tag for everything. I think I
> > > prefer the e.g. <uuid16>0x1002</uuid16> syntax. However, since this is
> > > XML there's no right or wrong way to do this. Perhaps others can chime
> > > in?
> >
> > my main reason is that the D-Bus Introspection goes this way. And I
> > personally find this way simpler and more intuitive.
>
> Ok in this case, agreed. I will make the necessary changes.
Great.
> > However this only works for "uuid", "text" and "url", because all others
> > might be used with special meaning from profile to profile.
>
> Yep, hence I made the int8..128 and uint8..128. I think this is unavoidable.
> This is also the reason why I explicitly specify uuid16..128. Do you think
> the uuid one is unnecessary?
It actually is, because the UUID-128 has a well defined representation
and it is simple to distinguish between UUID-16 and UUID-32. However if
someone wants to force another UUID, then we might should have them in
case.
> > Having the sized version around and retrieving a record from a remote
> > server gives you the chance to see the actual record how it is stored on
> > the remote side. For example some implementation use UUID-32 for no real
> > reason. Even if a UUID-16 would have been enough. I wanna see these
> > differences.
>
> I understand, but this is more of a developer thing. Can sdptool be made to
> fill this gap? It already has this functionality. I think the XML format
> should be kept as simple as possible, unless extra complexity is unavoidable.
I am not sure. For example if you wanna auto detect some special
devices, you might wanna have this extra bit of information. This can
become handy with all the special devices using the serial port profile
and are something special like a blood pressure device etc.
> Perhaps two dtds are in order. One that is "explicit" (you specify sizes for
> all elements, including Sequences and Alternates, Text, URL and UUID) and one
> that is not?
No. Two DTDs will make it too complex. We can have both ways within one
DTD and the registering application can use the simple one, while the
server will always hand out the detailed one. Leave the rest to the XML
parser.
> Something that occurred to me is that I think in the real implementation it
> would be a lot easier to specify the l2cap and rfcomm channels separately and
> just override the parsed SDP record. Don't know if this is good though.
> E.g.
> RegisterXMLRecordRFCOMM(byte[] xml, int rfcomm_channel)
> RegisterXMLRecordL2CAP...
I am against putting too much information into the methods itself. This
never gave us any advantage in the past. The Bluetooth SIG is inventing
new records all the time and in case of HCRP and HID you have two L2CAP
PSMs which makes this more complicated.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
> >
> > I can see your point on being lower case, so this is something I agree
> > with.
> >
> > I don't really like using the single data tag for everything. I think I
> > prefer the e.g. <uuid16>0x1002</uuid16> syntax. However, since this is
> > XML there's no right or wrong way to do this. Perhaps others can chime
> > in?
>
> my main reason is that the D-Bus Introspection goes this way. And I
> personally find this way simpler and more intuitive.
Ok in this case, agreed. I will make the necessary changes.
> > Why though? This is something that can be easily computed while parsing
> > the XML structure and creating the internal data representation. The
> > user should not have to deal with this implementation detail. I suppose
> > I'm open to adding text8, text16 and text32 tags in "expert" mode. But
> > how will we handle sequences and alternatives in this case?
>
> If you specify the DTD the size is not important. Say for example it is
> a UUID and the server can detect if it is a UUID-128, UUID-32 or UUID-16
> and so the actual application programmer can use the convenient way to
> specify the record with thinking about the actual sizes. The server will
> do the right thing.
>
Yep, I prefer this. See next.
> However this only works for "uuid", "text" and "url", because all others
> might be used with special meaning from profile to profile.
Yep, hence I made the int8..128 and uint8..128. I think this is unavoidable.
This is also the reason why I explicitly specify uuid16..128. Do you think
the uuid one is unnecessary?
>
> Having the sized version around and retrieving a record from a remote
> server gives you the chance to see the actual record how it is stored on
> the remote side. For example some implementation use UUID-32 for no real
> reason. Even if a UUID-16 would have been enough. I wanna see these
> differences.
I understand, but this is more of a developer thing. Can sdptool be made to
fill this gap? It already has this functionality. I think the XML format
should be kept as simple as possible, unless extra complexity is unavoidable.
Perhaps two dtds are in order. One that is "explicit" (you specify sizes for
all elements, including Sequences and Alternates, Text, URL and UUID) and one
that is not?
> The problem with SDP is that you can't make it really simple. So far we
> tried four times and nothing simple came around. This protocol and data
> representation is simply messed up.
I completely agree with the last sentence :)
> > > Actually at the moment you have to let the server pick the record
> > > handle, because specifying the handle doesn't work. It should work, but
> > > I never found the actual bug in the code that prevents it.
> > >
> > > Using the proposed way of the "data" element, we can have special
> > > values for "value" like "%channel" etc. that can be filled in by the
> > > server.
> >
> > I think this can be accomplished easily by using a hint attribute or a
> > special value, e.g.
> >
> > <uint16 type="auto_rfcomm_channel">0x0000</uint16>
> >
> > or
> >
> > <uint16>AUTO_RFCOMM_CHANNEL</uint16>
>
> I prefer the "%channel" way. Most people with programming skills will
> understand what it means.
>
Something that occurred to me is that I think in the real implementation it
would be a lot easier to specify the l2cap and rfcomm channels separately and
just override the parsed SDP record. Don't know if this is good though.
E.g.
RegisterXMLRecordRFCOMM(byte[] xml, int rfcomm_channel)
RegisterXMLRecordL2CAP...
> Regards
>
> Marcel
>
Thanks,
-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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> > > Here's the proposed DTD for SDP over XML. It closely follows the SDP
> > > profile doc. I wasn't sure whether sequences can be empty (which makes
> > > no sense to me), so I required at least one element in a sequence. The
> > > sizes for Text, URLs and Sequences was dropped. It can easily be
> > > inferred from parsing the document.
> >
> > since it is XML, keep everything lower-case and no extra "sdp" prefix.
> > It should be enough to call the root element "record". And I think it is
> > better and easier to use something like:
> >
> > <data type="uuid16" value="0x1002"/>
> >
>
> I can see your point on being lower case, so this is something I agree with.
>
> I don't really like using the single data tag for everything. I think I
> prefer the e.g. <uuid16>0x1002</uuid16> syntax. However, since this is XML
> there's no right or wrong way to do this. Perhaps others can chime in?
my main reason is that the D-Bus Introspection goes this way. And I
personally find this way simpler and more intuitive.
> > And to be fully in sync with the specification we need to differentiate
> > between text8, text16 and text32 (and of course for url, too). For
> > convenience we can then have all data types without the size value and
> > then the server will determine the most appropriate one by itself.
> >
>
> Why though? This is something that can be easily computed while parsing the
> XML structure and creating the internal data representation. The user should
> not have to deal with this implementation detail. I suppose I'm open to
> adding text8, text16 and text32 tags in "expert" mode. But how will we
> handle sequences and alternatives in this case?
If you specify the DTD the size is not important. Say for example it is
a UUID and the server can detect if it is a UUID-128, UUID-32 or UUID-16
and so the actual application programmer can use the convenient way to
specify the record with thinking about the actual sizes. The server will
do the right thing.
However this only works for "uuid", "text" and "url", because all others
might be used with special meaning from profile to profile.
Having the sized version around and retrieving a record from a remote
server gives you the chance to see the actual record how it is stored on
the remote side. For example some implementation use UUID-32 for no real
reason. Even if a UUID-16 would have been enough. I wanna see these
differences.
> For me I'd rather let the underlying system pick whatever is optimal. If I
> want to deal with such low level details, I'll program in the low-level API.
> Isn't the goal to be as user-friendly as possible?
The problem with SDP is that you can't make it really simple. So far we
tried four times and nothing simple came around. This protocol and data
representation is simply messed up.
> > > I'd like to get some feedback as to how to manage things like Record
> > > Handle, and RFCOMM/L2Cap channels, etc. For record handle I think it is
> > > easy, just remove that particular attribute and let the SDP server figure
> > > it out. For RFCOMM channel, etc it is more tricky. Should we use a
> > > magic value or just override it behind the scenes? We can always rely on
> > > the user to pick a correct channel as well (and fail registration if they
> > > pick a channel that is already in use)
> >
> > Actually at the moment you have to let the server pick the record
> > handle, because specifying the handle doesn't work. It should work, but
> > I never found the actual bug in the code that prevents it.
> >
> > Using the proposed way of the "data" element, we can have special values
> > for "value" like "%channel" etc. that can be filled in by the server.
>
> I think this can be accomplished easily by using a hint attribute or a special
> value, e.g.
>
> <uint16 type="auto_rfcomm_channel">0x0000</uint16>
>
> or
>
> <uint16>AUTO_RFCOMM_CHANNEL</uint16>
I prefer the "%channel" way. Most people with programming skills will
understand what it means.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
On Monday 23 October 2006 13:13, Marcel Holtmann wrote:
> Hi Denis,
>
> > Here's the proposed DTD for SDP over XML. It closely follows the SDP
> > profile doc. I wasn't sure whether sequences can be empty (which makes
> > no sense to me), so I required at least one element in a sequence. The
> > sizes for Text, URLs and Sequences was dropped. It can easily be
> > inferred from parsing the document.
>
> since it is XML, keep everything lower-case and no extra "sdp" prefix.
> It should be enough to call the root element "record". And I think it is
> better and easier to use something like:
>
> <data type="uuid16" value="0x1002"/>
>
I can see your point on being lower case, so this is something I agree with.
I don't really like using the single data tag for everything. I think I
prefer the e.g. <uuid16>0x1002</uuid16> syntax. However, since this is XML
there's no right or wrong way to do this. Perhaps others can chime in?
> And to be fully in sync with the specification we need to differentiate
> between text8, text16 and text32 (and of course for url, too). For
> convenience we can then have all data types without the size value and
> then the server will determine the most appropriate one by itself.
>
Why though? This is something that can be easily computed while parsing the
XML structure and creating the internal data representation. The user should
not have to deal with this implementation detail. I suppose I'm open to
adding text8, text16 and text32 tags in "expert" mode. But how will we
handle sequences and alternatives in this case?
For me I'd rather let the underlying system pick whatever is optimal. If I
want to deal with such low level details, I'll program in the low-level API.
Isn't the goal to be as user-friendly as possible?
> > I'd like to get some feedback as to how to manage things like Record
> > Handle, and RFCOMM/L2Cap channels, etc. For record handle I think it is
> > easy, just remove that particular attribute and let the SDP server figure
> > it out. For RFCOMM channel, etc it is more tricky. Should we use a
> > magic value or just override it behind the scenes? We can always rely on
> > the user to pick a correct channel as well (and fail registration if they
> > pick a channel that is already in use)
>
> Actually at the moment you have to let the server pick the record
> handle, because specifying the handle doesn't work. It should work, but
> I never found the actual bug in the code that prevents it.
>
> Using the proposed way of the "data" element, we can have special values
> for "value" like "%channel" etc. that can be filled in by the server.
I think this can be accomplished easily by using a hint attribute or a special
value, e.g.
<uint16 type="auto_rfcomm_channel">0x0000</uint16>
or
<uint16>AUTO_RFCOMM_CHANNEL</uint16>
>
> Regards
>
> Marcel
>
-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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> Here's the proposed DTD for SDP over XML. It closely follows the SDP profile
> doc. I wasn't sure whether sequences can be empty (which makes no sense to
> me), so I required at least one element in a sequence. The sizes for Text,
> URLs and Sequences was dropped. It can easily be inferred from parsing the
> document.
since it is XML, keep everything lower-case and no extra "sdp" prefix.
It should be enough to call the root element "record". And I think it is
better and easier to use something like:
<data type="uuid16" value="0x1002"/>
And to be fully in sync with the specification we need to differentiate
between text8, text16 and text32 (and of course for url, too). For
convenience we can then have all data types without the size value and
then the server will determine the most appropriate one by itself.
> I'd like to get some feedback as to how to manage things like Record Handle,
> and RFCOMM/L2Cap channels, etc. For record handle I think it is easy, just
> remove that particular attribute and let the SDP server figure it out. For
> RFCOMM channel, etc it is more tricky. Should we use a magic value or just
> override it behind the scenes? We can always rely on the user to pick a
> correct channel as well (and fail registration if they pick a channel that is
> already in use)
Actually at the moment you have to let the server pick the record
handle, because specifying the handle doesn't work. It should work, but
I never found the actual bug in the code that prevents it.
Using the proposed way of the "data" element, we can have special values
for "value" like "%channel" etc. that can be filled in by the server.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> > The current XML format is for both, but it makes some assumptions and
> > simplifications. In 99% of the use cases this is enough and for the
> > other 1% you have to deal with the binary format. And this is totally
> > fine in case of easy use.
>
> Ok, cool. I'm just worried about code duplication and maintenance of multiple
> formats. E.g. looking at the new service framework (which is something that
> we're very interested in for instance), it takes a binary formatted sdp
> record. Would there also be a version for XML?
yes, there will be a XML version for registering SDP records. However
someone has to write it.
> > Actually it should be enough to have support for libexpat and libxml2
> > since one of these is required by D-Bus anyway. So I would start with
> > libexpat for now. It should be common/sdp-expat.c and I will create the
> > autoconf magic around it.
>
> Ok, I will work on a parser based on expat.
Add the function prototypes to common/sdp-xml.h and the actual
implementation to common/sdp-expat.c and an implementation that returns
an error to common/sdp-dummy.c to make it compile with systems where the
Expat library is not available.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
> I simply was too lazy to do the full conversion. Thanks for fixing my
> laziness ;)
>
> The only thing that I am not fully agree with is the encoding attribute
> for string. I have to check up on the best way to achieve the support of
> binary strings.
>
>>From what I read, this is the preferred way, but I'm definitely open to
suggestions.
> The current XML format is for both, but it makes some assumptions and
> simplifications. In 99% of the use cases this is enough and for the
> other 1% you have to deal with the binary format. And this is totally
> fine in case of easy use.
Ok, cool. I'm just worried about code duplication and maintenance of multiple
formats. E.g. looking at the new service framework (which is something that
we're very interested in for instance), it takes a binary formatted sdp
record. Would there also be a version for XML?
> Actually it should be enough to have support for libexpat and libxml2
> since one of these is required by D-Bus anyway. So I would start with
> libexpat for now. It should be common/sdp-expat.c and I will create the
> autoconf magic around it.
Ok, I will work on a parser based on expat.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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.
I simply was too lazy to do the full conversion. Thanks for fixing my
laziness ;)
The only thing that I am not fully agree with is the encoding attribute
for string. I have to check up on the best way to achieve the support of
binary strings.
> > 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.
The current XML format is for both, but it makes some assumptions and
simplifications. In 99% of the use cases this is enough and for the
other 1% you have to deal with the binary format. And this is totally
fine in case of easy use.
> 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.
You can pre-calculate these binary blobs. And yes, in case you really
need to have full control you have to obey to the GPL or re-write the
binary SDP parser from scratch. I have no problem with that and actually
I don't care. The support of binary only software is definitely not my
top priority.
> > 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.
Actually it should be enough to have support for libexpat and libxml2
since one of these is required by D-Bus anyway. So I would start with
libexpat for now. It should be common/sdp-expat.c and I will create the
autoconf magic around it.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi 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.
>
> I agree we should replace string_t by sdp_buf_t since this avoids an extra
> strlen. However, I think that the buffer should be grown by factors. Your
> proposed solution would call realloc many times, as the append function is
> called quite frequently with small strings, but this is no biggie.
>
> Would the attached patch be better?
looks good to me.
Claudio, please review it and then commit this to the CVS.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 11/8/06, Denis KENZIOR <[email protected]> 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
> [email protected]
> 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.
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel