Iain,
when this comes up, i always refer people for openssl's err(3)
Well, I looked at that and I'm not sure what the point of all that is..
seems very complex for what it is, but maybe some complexity is warranted
when you have a threaded application.
what i'm trying to say is
1) mixing errno-style and custom style error reporting is, imo, a bad
idea. doing so usually result in complicated and confusing, imo, code.
for this reason, i usually choose one style for a particular piece of
code and stick with it.
2) given a choice between errno-style and custom style error reporting,
i usually choose custom style *with* reusing errno values for error
codes. this way custom error reporting is equivalent to "glorified
errno", but in the same time i have the flexibility to completely
replace errno values with something else if needed. this approach is
something learned from personal experience and it worked for me many times.
3) i believe that data encapsulation and reentrant, thread-safe api
design are good things. for this reason session-based api is used in
libsdp(3). i choose to save error codes inside the session because it
fits this model. i'm not saying that is the only right way to do things.
i'm just trying to explain how i came to write this code.
When I write code, my ideal would preferably be 'simplicity and elegance'
and I think in this case, you went too far and it just got complicated for
no great reason..
perhaps. sdp protocol and data structures are flexible. it is possible
to slice and dice the data any way one wants. since bluetooth
specification is a living thing and keeps changing, i opt out for more
complicated design.
there is, of course, little problem. because the errno values are reused, in
some cases, it is not possible to say if syscall has failed or something
inside library has failed.
there does not (imo) need to be any such distinction in reality - the
application program gets a notice of failure on a specific function (by a
bad return code), and what the failure is. It doesnt matter where the
error was. eg if sdp_open() returns ENOMEM then you know there was some
memory failure. It is not important if it was sdp_open() that failed to
allocate the handle structure, or if it was the kernel that failed to
allocate the PCB. Of course, you as the library author are responsible to
make sure that you dont have bugs that cause error returns with valid
application arguments.
i disagree with you here. in order to troubleshoot any problem one needs
to know what went wrong and why. it just saves lots of time down the
road (imo).
i appreciate your comments and respect your position. so, lets just
agree to disagree here :) whether you choose to use libsdp(3) or not, i
personally will respect and support your choice. i'm sure others will do
the same. both implementations already have quite a few differences, so
adding one more should not be a big issue :)
i think, you do have a point about sdpd(8) profile registration and
libsdp(3) attribute parsing. i will try to address these (and if anyone
wants to help please feel free to jump in). and, of course, please feel
free to continue to ask questions, submit patches etc. its all good stuff :)
specification is not clear at all. I thought of some way, possibly
extending the attrlist that you used for sdp_search() to specify values
that could be automatically extracted and leaving all the parsing inside
the library.
well, here is what i think. sdp(3) client knows *exactly* what it is looking
for. usually it is only required to get a few (less than 3) attributes to get
all the information.
btw, I wonder why you made the attrlist take a range instead of an
attribute? It leaves us with this kind of thing..
/* List of the attributes we are looking for */
static uint32_t attrs[] =
{
SDP_ATTR_RANGE( SDP_ATTR_SERVICE_RECORD_HANDLE,
SDP_ATTR_SERVICE_RECORD_HANDLE),
SDP_ATTR_RANGE( SDP_ATTR_SERVICE_CLASS_ID_LIST,
SDP_ATTR_SERVICE_CLASS_ID_LIST),
SDP_ATTR_RANGE( SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST,
SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST),
SDP_ATTR_RANGE( SDP_ATTR_BLUETOOTH_PROFILE_DESCRIPTOR_LIST,
SDP_ATTR_BLUETOOTH_PROFILE_DESCRIPTOR_LIST)
};
.. though I'm not sure how often how often a range of attributes could be
desireable .. in fact, this could be cleared with another macro like:
#define SDP_ATTR(attr) SDP_ATTR_RANGE(attr, attr)
[later] actually, I'm guessing this is related to the spec somehow -
looking at the BlueZ sdp_lib.h include file which seems to be the
documentation, they look to use the same concept.
yes. attributes can be request in two ways
1) as individual uint16_t attribute id
2) as uint32_t attribute range (lo, hi)
in order to simplify the code i decided to always use ranges even if one
attribute is requested. this creates slightly bigger sdp pdu's but (imo)
makes api simpler. the SDP_ATTR(attr) you suggesting is fine with me.
sdp(3) client knows *exactly* what the format of the
attributes should be. so, sdp(3) library should provide simple api to locate
given element of given type in raw data and extract data from it. imo, more
intelligent parsing could require sdp(3) to actually know about the profile
client is trying use.
Yes was thinking along those lines.. the client would provide a structure
detailing how to parse the required attributes where to put the values.
may be. so far i have not seen a need for that.
thanks,
max
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
