implement RFCOMM Connect and Disconnect methods
PATCH 1/1 implement RFCOMM Connect and Disconnect methods
Hi,
I sent this a couple of weeks ago, but didn't get any feedback. This patch implements the Connect and Disconnect methods in the org.bluez.RFCOMM namespace. I've changed it to use integers for services rather than the string identifiers for a couple of reasons:
1) Nothing else seems to actually use the strings right now, even when the docs suggest they do
2) The service values don't appear to be complete and don't deal with the case of having multiple services of the same general type on a device
Based on previous discussion with Marcel, this patch may not be ideal since it doesn't deal with the case of the whether or not cached values are valid. However, if the API is considered correct, then it would be nice to add it with a note that it may not work under certain circumstances and then fix that at some later stage.
? .deps
? Makefile
? Makefile.in
Index: dbus-api.txt
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-api.txt,v retrieving revision 1.40
dbus-api.txt +8 -12
@@ -895,11 +895,11 @@ Interface org.bluez.RFCOMM Object path /org/bluez/{hci0,hci1,...} -Methods string Connect(string address, string service) +Methods string Connect(string address, int service) This creates a connection to a remote RFCOMM based - service. The service string can either be a UUID-16, - a UUID-32, a UUID-128 or a service abbreviation. + service. The service should be a serviceid as + provided by the org.bluez.SDP methods. The return value will be the path of the newly created RFCOMM TTY device (for example /dev/rfcomm0).
@@ -907,11 +907,7 @@ If the application disconnects from the D-Bus this connection will be terminated. - Valid service values: "vcp", "map", "pbap", "sap", - "ftp", "bpp", "bip", "synch", - "dun", "opp", "fax", "spp" - - void CancelConnect(string address, string service) + void CancelConnect(string address, int service) This method cancels a previous Connect method call.
@@ -971,13 +967,13 @@ Interface org.bluez.SDP Object path /org/bluez/{hci0,hci1,...} -Methods array{string} GetIdentifiers(string address) +Methods array{int} GetIdentifiers(string address) - array{string} GetIdentifiersByService(string address, string service) + array{int} GetIdentifiersByService(string address, string service) - string GetUUID(string identifier) + string GetUUID(int identifier) - string GetName(string identifier) + string GetName(int identifier) string RegisterRFCOMM(string service, byte channel)
Index: dbus-rfcomm.c
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-rfcomm.c,v retrieving revision 1.9
dbus-rfcomm.c +79 -8
103 lines not on this page · raw message
Index: dbus-sdp.c
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-sdp.c,v
retrieving revision 1.8
dbus-sdp.c +1 -1
@@ -855,7 +855,7 @@ } -static sdp_record_t *find_record (const char *address,int id) +sdp_record_t *find_record (const char *address,int id) {struct slist *lp, *lr;struct service_provider *p;
Index: dbus-test
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-test,v
retrieving revision 1.22
dbus-test +7 -1
@@ -45,6 +45,7 @@ "ClearRemoteAlias", "LastSeen", "LastUsed", + "ConnectRemoteDevice", "DisconnectRemoteDevice", "CreateBonding", "CancelBondingProcess",
@@ -343,9 +344,14 @@ print self.device.LastUsed(self.cmd_args[0]) else: print 'Usage: %s -i <dev> LastUsed address' % self.name + elif self.cmd == 'ConnectRemoteDevice': + if len(self.cmd_args) == 1: + print self.device.ConnectRemoteDevice(self.cmd_args[0]) + else: + print 'Usage: %s -i <dev> ConnectRemoteDevice address' % self.name elif self.cmd == 'DisconnectRemoteDevice': if len(self.cmd_args) == 1: - print self.device.LastUsed(self.cmd_args[0]) + print self.device.DisconnectRemoteDevice(self.cmd_args[0]) else: print 'Usage: %s -i <dev> DisconnectRemoteDevice address' % self.name elif self.cmd == 'CreateBonding':
Index: dbus.h
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus.h,v
retrieving revision 1.96
dbus.h +2 -0
@@ -200,4 +200,6 @@int discoverable_timeout_handler (void *data); +sdp_record_t *find_record (const char *address,int identifier); +#endif /* __H_BLUEZ_DBUS_H__ */
Signature · 11 lines
Matthew Garrett | [email protected] ------------------------------------------------------------------------- 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 Holtmann
maintainerHi Matthew,
Quoted 11 lines
I sent this a couple of weeks ago, but didn't get any feedback. This patch implements the Connect and Disconnect methods in the org.bluez.RFCOMM namespace. I've changed it to use integers for services rather than the string identifiers for a couple of reasons:
1) Nothing else seems to actually use the strings right now, even when the docs suggest they do
2) The service values don't appear to be complete and don't deal with the case of having multiple services of the same general type on a device
Quoted 5 lines
Based on previous discussion with Marcel, this patch may not be ideal since it doesn't deal with the case of the whether or not cached values are valid. However, if the API is considered correct, then it would be nice to add it with a note that it may not work under certain circumstances and then fix that at some later stage.
I haven't payed much attention to the RFCOMM parts of our D-Bus API since I declared it as experimental and it might still change. However one thing is that we wanna use strings. They are more flexible and if you use languages like Python they can come in handy.
In this case for example you might use "spp" (service name) or "0x10000" (record handle) to connect to a specific RFCOMM channel.
The SDP caching is still something that needs a lot of thinking before we will finally solve it. It is not as easy as people thing and always requesting a SDP record first is not a good idea either. However a lot of this depends on how broken the SDP records of the remote devices are.
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
Quoted 7 lines · Marcel Holtmann
I haven't payed much attention to the RFCOMM parts of our D-Bus API since I declared it as experimental and it might still change. However one thing is that we wanna use strings. They are more flexible and if you use languages like Python they can come in handy.
In this case for example you might use "spp" (service name) or "
0x10000" (record handle) to connect to a specific RFCOMM channel.
I'm not entirely clear on what a service name represents. Is it a specific service, or is it the profile implemented by that service? What string should represent non-standard services? As an example, my phone has a service called "Nokia OBEX PC Suite Services". If I want to use that via the DBus interface, I'll presumably need to use the record handle anyway?
Quoted 4 lines
The SDP caching is still something that needs a lot of thinking before we will finally solve it. It is not as easy as people thing and always requesting a SDP record first is not a good idea either. However a lot of this depends on how broken the SDP records of the remote devices are.
I agree that always requesting the SDP record first is less than ideal, but I'd argue that it's better to have suboptimal functionality than no functionality :)
Thanks,
Signature · 11 lines
Matthew Garrett | [email protected] ------------------------------------------------------------------------- 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 Matthew,
Quoted 6 lines · Matthew Garrett
I'm not entirely clear on what a service name represents. Is it a specific service, or is it the profile implemented by that service? What string should represent non-standard services? As an example, my phone has a service called "Nokia OBEX PC Suite Services". If I want to use that via the DBus interface, I'll presumably need to use the record handle anyway?
Or its UUID (presumably 128bit) in string format. It seems that we'd have three different ways for specifying the target service:
1. friendly name (e.g. "ftp")
2. record handle
3. UUID
Johan
-------------------------------------------------------------------------
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
Quoted 5 lines · Johan Hedberg
Or its UUID (presumably 128bit) in string format. It seems that we'd have three different ways for specifying the target service:
1. friendly name (e.g. "ftp")
2. record handle
3. UUID
Ok. So we pass all of these as strings, parse them in the method and then connect to the appropriate channel? That seems doable.
Signature · 11 lines
Matthew Garrett | [email protected] ------------------------------------------------------------------------- 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
Right. How about this (not heavily tested, more proof of concept) - it removes the unimplemented Connect and CancelConnect methods, and replaces them with ConnectByUUID, ConnectByService and ConnectByHandle methods with the appropriate CancelConnect methods.
Index: dbus-api.txt
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-api.txt,v retrieving revision 1.41
dbus-api.txt +42 -5
@@ -901,11 +901,11 @@ Interface org.bluez.RFCOMM Object path /org/bluez/{hci0,hci1,...} -Methods string Connect(string address, string service) +Methods string ConnectByService(string address, string service) This creates a connection to a remote RFCOMM based - service. The service string can either be a UUID-16, - a UUID-32, a UUID-128 or a service abbreviation. + service. The service string must be a service + abbreviation. The return value will be the path of the newly created RFCOMM TTY device (for example /dev/rfcomm0).
@@ -917,9 +917,46 @@ "ftp", "bpp", "bip", "synch", "dun", "opp", "fax", "spp" - void CancelConnect(string address, string service) + void CancelConnectByService(string address, string service) - This method cancels a previous Connect method call. + This method cancels a previous ConnectByService method + call. + + string ConnectByUUID(string address, string uuid) + + This creates a connection to a remote RFCOMM based + service. The uuid string must be a UUID-128. + + The return value will be the path of the newly + created RFCOMM TTY device (for example /dev/rfcomm0). + + If the application disconnects from the D-Bus this + connection will be terminated. + + void CancelConnectByUUID(string address, string uuid) + + This method cancels a previous ConnectByUUID method + call. + + string ConnectByHandle(string address, uint32 handle) + + This creates a connection to a remote RFCOMM based + service. The handle must be a servicerecord handle. + + The return value will be the path of the newly + created RFCOMM TTY device (for example /dev/rfcomm0). + + If the application disconnects from the D-Bus this + connection will be terminated. + + Valid service values: "vcp", "map", "pbap", "sap", + "ftp", "bpp", "bip", "synch", + "dun", "opp", "fax", "spp" + + void CancelConnectByHandle(string address, string uuid) + + This method cancels a previous ConnectByHandle method + call. string ConnectByChannel(string address, byte channel)
Index: dbus-rfcomm.c
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-rfcomm.c,v retrieving revision 1.10
dbus-rfcomm.c +307 -10
344 lines not on this page · raw message
Index: dbus-sdp.c
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-sdp.c,v
retrieving revision 1.9
dbus-sdp.c +71 -0
77 lines not on this page · raw message
Index: dbus.h
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus.h,v
retrieving revision 1.98
dbus.h +4 -0
@@ -214,4 +214,8 @@int discoverable_timeout_handler (void *data); +sdp_record_t *find_record_by_uuid (const char *address,uuid_t *uuid); +sdp_record_t *find_record_by_handle (const char *address,int handle); +uint16_t sdp_str2svclass (const char *str); +#endif /* __H_BLUEZ_DBUS_H__ */
Signature · 11 lines
Matthew Garrett | [email protected] ------------------------------------------------------------------------- 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 Holtmann
maintainerHi Matthew,
Quoted 4 lines
Right. How about this (not heavily tested, more proof of concept) - it removes the unimplemented Connect and CancelConnect methods, and replaces them with ConnectByUUID, ConnectByService and ConnectByHandle methods with the appropriate CancelConnect methods.
thanks for the patch, but what is the problem with sticking to Connect and CancelConnect and use their service string to identify UUID, handle or service name bases connections.
Remember that the goal of the D-Bus based API is to make it easy for the applications. So they can give us whatever they have and we then request the right information from the remote device and then connect to the right RFCOMM channel.
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
Quoted 3 lines · Marcel Holtmann
thanks for the patch, but what is the problem with sticking to Connect and CancelConnect and use their service string to identify UUID, handle or service name bases connections.
I'm not quite clear on what you mean here. The service string seems unacceptable because it requires bluez to have a table of every possible service and UUID in existence. Or are we talking about different things? Right now, the API gives us the following things that potentially identify an object:
1) The identifiers returned by GetIdentifiers (currently an arbitrary but unique integer, despite dbus-api.txt claiming it returns strings)
2) The UUID
3) The service handle
4) The ascii service string
My implementation provides connect methods for (2), (3) and (4). You didn't seem too happy about my patch providing support for (1), so I've dropped it :) Or do you just mean that there should be a single method and it should work out which piece of information has been passed by the app? In that case, I didn't implement it that way because determining the type was a bit of a pain and struck me as potentially fragile.
Signature · 11 lines
Matthew Garrett | [email protected] ------------------------------------------------------------------------- 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 Holtmann
maintainerHi Matthew,
Quoted 16 lines
Quoted 3 lines
thanks for the patch, but what is the problem with sticking to Connect and CancelConnect and use their service string to identify UUID, handle or service name bases connections.
I'm not quite clear on what you mean here. The service string seems unacceptable because it requires bluez to have a table of every possible service and UUID in existence. Or are we talking about different things? Right now, the API gives us the following things that potentially identify an object:
1) The identifiers returned by GetIdentifiers (currently an arbitrary but unique integer, despite dbus-api.txt claiming it returns strings)
2) The UUID
3) The service handle
4) The ascii service string
Quoted 6 lines
My implementation provides connect methods for (2), (3) and (4). You didn't seem too happy about my patch providing support for (1), so I've dropped it :) Or do you just mean that there should be a single method and it should work out which piece of information has been passed by the app? In that case, I didn't implement it that way because determining the type was a bit of a pain and struck me as potentially fragile.
I meant exactly that. The method should work out what information got passed to it. Of course this might not be easy to implement, but that is not the point behind this API. The whole API is designed to make it easy for all kind of applications. And the main focus is not the C language.
We have been through a lot of trouble and parts of hcid look really horrible, but for the end user (the application) the interface is easy to use.
I also don't see the problem here. The ASCII service string are a predefined list of names that actually match to specific UUID. Since in the end we will implement all needed service names for all known profiles, we only need to support UUID128. These have a unique form and are kinda easy to detect. If the provided UUID128 matches the Bluetooth base string, then we can internally use UUID32 or UUID16. As simple as that. For the record handles we give them in hex and so they are also easy to identify. And I would check the string in this order.
And as said, this might require a little bit more code in hcid, but that is the price to pay if we wanna have a simple API for the application and I am paying it gladly.
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
Quoted 4 lines · Marcel Holtmann
I meant exactly that. The method should work out what information got passed to it. Of course this might not be easy to implement, but that is not the point behind this API. The whole API is designed to make it easy for all kind of applications. And the main focus is not the C language.
Ok, cool. Now I know what to aim for, I'll head back to that :)
Quoted 8 lines
I also don't see the problem here. The ASCII service string are a predefined list of names that actually match to specific UUID. Since in the end we will implement all needed service names for all known profiles, we only need to support UUID128. These have a unique form and are kinda easy to detect. If the provided UUID128 matches the Bluetooth base string, then we can internally use UUID32 or UUID16. As simple as that. For the record handles we give them in hex and so they are also easy to identify. And I would check the string in this order.
Ok, makes sense.
Quoted 3 lines
And as said, this might require a little bit more code in hcid, but that is the price to pay if we wanna have a simple API for the application and I am paying it gladly.
Sure. I'll send a new patch tomorrow.
Signature · 11 lines
Matthew Garrett | [email protected] ------------------------------------------------------------------------- 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 Holtmann
maintainerHi Matthew,
Quoted 6 lines
Quoted 4 lines
I meant exactly that. The method should work out what information got passed to it. Of course this might not be easy to implement, but that is not the point behind this API. The whole API is designed to make it easy for all kind of applications. And the main focus is not the C language.
Ok, cool. Now I know what to aim for, I'll head back to that :)
I think a lot of people missed the discussions behind the API since we did them basically behind closed doors. The main focus will always be the client application. You really have to think the other way around.
Quoted 10 lines
Quoted 8 lines
I also don't see the problem here. The ASCII service string are a predefined list of names that actually match to specific UUID. Since in the end we will implement all needed service names for all known profiles, we only need to support UUID128. These have a unique form and are kinda easy to detect. If the provided UUID128 matches the Bluetooth base string, then we can internally use UUID32 or UUID16. As simple as that. For the record handles we give them in hex and so they are also easy to identify. And I would check the string in this order.
Ok, makes sense.
And the weird indentifiers are free formed strings that doesn't match any of the other categories. And since the server will hand them out it is an easy requirement to fulfill. These are also not meant to have any meaning. In general they can be random garbage. The server knows what to do with them.
You will also see that we love using strings, because in languages like Python they are so easy to handle. If it is not an integer by definition we might go with a string as type, because it is more flexible.
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
Ok, how's this? Again not heavily tested, but just to make sure that the style is right.
Index: dbus-api.txt
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-api.txt,v retrieving revision 1.41
dbus-api.txt +2 -2
@@ -904,8 +904,8 @@ Methods string Connect(string address, string service) This creates a connection to a remote RFCOMM based - service. The service string can either be a UUID-16, - a UUID-32, a UUID-128 or a service abbreviation. + service. The service string can either be a UUID-128, + a service abbreviation or a record handle. The return value will be the path of the newly created RFCOMM TTY device (for example /dev/rfcomm0).
Index: dbus-rfcomm.c
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-rfcomm.c,v retrieving revision 1.10
dbus-rfcomm.c +122 -4
151 lines not on this page · raw message
Index: dbus-sdp.c
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-sdp.c,v
retrieving revision 1.9
dbus-sdp.c +71 -0
77 lines not on this page · raw message
Index: dbus.h
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus.h,v
retrieving revision 1.98
dbus.h +4 -0
@@ -214,4 +214,8 @@int discoverable_timeout_handler (void *data); +sdp_record_t *find_record_by_uuid (const char *address,uuid_t *uuid); +sdp_record_t *find_record_by_handle (const char *address,int handle); +uint16_t sdp_str2svclass (const char *str); +#endif /* __H_BLUEZ_DBUS_H__ */
Signature · 11 lines
Matthew Garrett | [email protected] ------------------------------------------------------------------------- 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] RFComm auth/encrypt
Marcel,
I'm trying to use the OpenOBEX bluetooth functions, but want to control the service level security options. Since OpenOBEX does a listen for me, I can't set the security options before a listen occurs. So my question is:
On a rfcomm server socket, when is the right time to set the link_mode flags? E.g. do I have to set it before the listen call? Or setting them at any point after the listen is OK (and actually works) as well?
E.g. Here's what I'm trying to do:
BtOBEX_ServerRegister(self, &bdaddr, channel); setsockopt(OBEX_GetFD(self), SOL_RFCOMM, RFCOMM_LM, &lm, sizeof(lm));
And on the client side, it seems that the client can request security options to be set as well. Again, when is the right time to do this? After the socket call but before the connect? Can authentication be requested after the client socket is connected?
-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 Matthew,
Quoted 2 lines · Matthew Garrett
Ok, how's this? Again not heavily tested, but just to make sure that the style is right.
The patch is now commited to the CVS along with some coding style changes and a few other fixes. It's a good start, but one major thing missing is that the Connect method should initiate an SDP query to the remote device if necessary (if the record isn't found in the local cache) to find out the correct channel to connect to.
Johan
-------------------------------------------------------------------------
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