Iain Hibbert wrote:
On Fri, 7 Nov 2008, Guido Falsi wrote:
Iain Hibbert wrote:
The attribute ID list should be in ascending order according to
the specification. This means though that some logic could be
wrong because the protocol descriptor list for any given service
class would likely appear before the service name in the response
attribute list and you would use the wrong channel..
Uhm, I did not get this detail in the specification.
You can find this in the small print of the SDP spec sections
relating to ServiceSearch and ServiceSearchAttribute requests, in the
AttributeIDList box.
I guess its so that a server can do a straight pass through search
without having to loop up and down the list, but I don't know if that
would work out simpler or not in practice. Obviously the Nokia people
thought not, as it worked anyway :)
After some reading, some coding and some experimenting I think I found
what is happening.
I have this code(I hope mozilla will not mangle this too much):
uint32_t attrs[] =
{
SDP_ATTR_RANGE(
SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID+SDP_ATTR_SERVICE_NAME_OFFSET,
SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID+SDP_ATTR_SERVICE_NAME_OFFSET),
SDP_ATTR_RANGE(
SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST,
SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST),
};
so I define 2 ranges with a single attribute in each. This one defines
the order in which objects are returned.
Since I think code written the way you suggested is cleaner and more
readable I'll just swap the two ranges and have it work the way you said.
I think FreeBSD's sdp is making 2 requests in this case...Or maybe
forcing the order to be the same as the request.
--
Guido Falsi <[EMAIL PROTECTED]>
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
