Iain,
it all boils down to what do we think libsdp(3) is. is it
a) a generic library that only operates inside the sdp protocol scope, i.e. it
is only aware of sdp data elements and their types and *NOT* of the meaning of
these data elements to the end user application
Yes, thats what I would like (I think we concur)..
ah, good :)
obviously libsdp(3) can (and probably should) include more high-level
functions to parse "well-known" attributes and their values.
and I think it would be nice if this was not necessary for ease of use.
sure
after thinking about it, i'm somewhat confused by your statement "...telling
it what to look for...".
...
2) from what i understand, libsdp(3) must know how to parse attribute given in
sdp_parse_t. in other words, libsdp(3) must know that
SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST is a sequence in a specific format, etc. i
think this means that if there is a new attribute and/or value format
libsdp(3) needs modification.
No, my thought was to provide a fairly simple 'description' of the problem
that you want solved.
eg
First, we tell the server, we are interested a particular service (eg DUN)
and we get the PDU from the server. The PDU can be opaque for all we care,
or it can be an array of attributes as is currently the case or flat as
you suggested earlier. Thats not so important (I'm considering it opaque
since as a client I dont want to parse it myself)
So, if the description goes like this
for ATTRIBUTE=PROTOCOL_DESCRIPTOR_LIST, we want to find
UUID RFCOMM
INT8 => <address>
it scans the PDU and for each attribute looks at its list to see if it has
anything for that attribute ID. When it has something, it scans the
attribute chunk using the list we gave it - ie, in this case, for the
PROTOCOL_DESCRIPTOR_LIST attribute it first wants to find a UUID matching
RFCOMM before it can proceed, then it must find an INT8 value which it
stores in the address given. When all the attributes are parsed, it
returns and you just examine the addresses you gave it to see if contents
have been updated.
ah, ok, i think, i missed you point in earlier emails. so, just to make
sure i understood you correctly this time :) you are suggesting to
implement some sort of "mini-program" that sdp parser would "execute"
and give you back the results. each sdp client then will have its own
"mini-program" for sdp parser designed to parse sdp response and look
for specified (by the "mini-program") attributes and values.
right, please let me briefly describe what i had in mind for libsdp(3)
parsing. this would correspond to the item (a) from above.
This is good and is necessary in any case, but my thought is that it still
throws a lot of the parsing and interpretation onto the client program so
I would like to take a step further. So far as I can see, it should be
possible to parse the PDU without needing to know the complete structure
as unknown portions can easily be skipped.
The 'descriptor' language would obviously have to be a little more complex
than as described above, but since any client would usually only want to
parse a particular type of service then if it can be defined in a static
structure manner that makes it easy to program and it should be clear to
see what it is extracting from where.
If it turns out that providing a bunch of macros to construct the
descriptor 'program' dynamically is easier and neater then thats Ok too..
that is an interesting approach. i'm sure it is possible to do things
this way. the only question arises is how much complexity would we like
in this "mini-program"?
lets consider the following example. a minimal "protocol descriptor
list" for rfcomm based service would look something like
seq8 len8 - 2 bytes
seq8 len8 - 2 bytes
uuid16 value16 - 3 bytes L2CAP
seq8 len8 - 2 bytes
uuid16 value16 - 3 bytes RFCOMM
uint8 value8 - 2 bytes RFCOMM param #1
=========
14 bytes
as you know, rfcomm channel number is in so called "protocol specific
parameter #1". lets say, for argument sake, the descriptor also has
protocol specific parameter #2 and #3. and also say that a client in
interested in value of protocol specific parameter #1 and #3 (i.e. skip
#2) *if* #2 and #3 are present. because all values are simply uint8
there is no way to distinguish between them. now, lets assume that we
can work around this problem by putting dummy parser "mini-program" data
structure that says that we can have parameters #1, #2 and #3. data
pointer for #2 is null, indicating that we do not care about the value.
data pointers for #1 and #3 are not null. seems reasonable? may be. i
looked at few profile documents (specifically sdp records), and, it
seems that some profile may have optional attributes/values. so whatever
the "language" we invent for sdp parsing, imo, should have some sort of
conditional parsing. and, btw, i think, you were asking/suggesting if
you could run rfcomm on different l2cap psm, and, in this case you would
need to add uint16 psm parameter to l2cap protocol in the descriptor :)
thanks,
max
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
