Hi Shane, Thank you very much for your feedback.
The mailing list address has been changed from [email protected] to [email protected]. Regarding OBEX, we only provide a simple API to support file transfer in 1.2. We are leveraging the platform OBEX implementation. i.e. we won't have a Qt API to fully implement OBEX specification. We will look at the extensibility again. Thanks again. Kind regards, Min -----Original Message----- From: ext [email protected] [mailto:[email protected]] Sent: Friday, 14 January 2011 11:06 PM To: Shin Minjung (Nokia-MS-Qt/Brisbane) Subject: FW: TP1.2 bluetooth API Hi Minjung, I posted this to the mailing list, but it didn't seem to arrive. A lot of these suggestions can be done after 1.2, but there are some issues where the 1.2 API would be hard to maintain. The OBEX API in particular doesn't look ready for release, as it looks hard to implement other obex operations within that framework. Best Regards, Shane Kearns -- Communications with Accenture or any of its group companies ("Accenture Group") including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with company policy. Accenture Group does not accept service by e-mail of court proceedings, other processes or formal notices of any kind. Accenture means Accenture (UK) Limited (registered number 4757301), Accenture Technology Solutions Limited (registered number 4442596), or Accenture HR Services Limited (registered number 3957974), all registered in England and Wales with registered addresses at 30 Fenchurch Street, London EC3M 3BD, as the case may be. -----Original Message----- From: Kearns, Shane Sent: Thursday, January 13, 2011 14:39 To: '[email protected]' Subject: TP1.2 bluetooth API Hi, I have some review comments on the APIs for Bluetooth in the 1.2 tech preview. My background is having debugged many of the S60 bluetooth profiles, so there may be a symbian bias. I'm fairly familiar with the bluetooth 2.x specifications but don't know how many of the optional features are currently implemented in bluez. The email is quite long, but broken down by class in the API. * QBluetooth::SecurityFlags I would expect to see some flags related to "man in the middle" protection levels here. These are used in Bluetooth 2.1 to determine what types of secure simple pairing are allowed. With the current API, the backend would need to pick a default (which might prevent a bluetooth profile being implemented according to spec if using Qt Mobility) On symbian, the equivalent is TBTAccessRequirementsMitmProtection If the backend is implemented on top of a pre 2.1 stack, it can ignore these flags and only apply the BT1.0 flags you already defined. (S60 3.x has a 2.0 stack, S60 5.0 has a 2.1 stack) * QBluetoothDeviceDiscoveryAgent Quite OK, but the list of errors is inadequate. (unknown error for everything) "bluetooth is switched off" for example. Possible API extensions: There should be an option to skip name lookup (it's much faster, suitable for some non UI usage) (maybe) There should be an option to filter on class of device (not good to rely on, e.g. both a printer and a computer could offer the printing service) There should be an option to filter on service uuid In the documentation you should warn people that the finished() signal could take minutes to come. (e.g. office environment where everyone has a phone and PC with bluetooth discoverable) * QBluetoothDeviceInfo Needs a DataCompleteness function for the name (name request can time out) majorDeviceClass() returns an enum, but that doesn't define all possible values. (major classes 9-30 are reserved but could be assigned at any time) I don't think manufacturerSpecificData() needs the bool pointer, as the caller can use isEmpty() / isNull() on the QByteArray returned. * QBluetoothLocalDevice setHostMode and powerOn should be requests (power on can be slow), and they can fail so you need a way to signal failure. The hostModeChanged signal can be used for success. Should there be a powerOff? or is setHostMode(0) sufficient? Should there be a setName? (which can also fail) If the device is connectable and discoverable, is the host mode 3 (as in the HCI) or 2 (since being discoverable but not connectable is not useful)? Either way doc needs clarification. * QBluetoothServiceDiscoveryAgent Since symbian's SAX style API was so hard to use and S60's API was broken, I'm sympathetic to this API returning complete service records. To avoid excessive memory use, make sure that it is possible to call clear() from the serviceDiscovered() signal handler. The combination of all devices and full discovery is particularly dangerous. (although some bluetooth stacks stupidly require user intervention to allow connections to SDP so it will get stuck in the tar pit in practice) Why is the bluetooth address a constructor parameter, but the uuid filter is a property? It would make sense to set bluetooth address in the same way as uuid filter. * QBluetoothServiceInfo SDP data element sets can contain data element alternates and vice versa. The Alternative and Sequence inner classes contain lists of QVariant, you don't appear to publish the integer user type for casting. is QVariant::canConvert<QBluetoothServiceInfo::Alternative>() and QVariant::value() sufficient for all cases? socketProtocol() should return an int, and the enum values should be defined to match the bluetooth assigned numbers spec. (e.g. QBluetoothServiceInfo::L2capProtocol = 0x100 and QBluetoothServiceInfo::RfcommProtocol = 0x3). That way the application can understand protocols that QBluetooth does not. can protocolServiceMultiplexer() and serverChannel() be combined into a single API? The socketProtocol() tells you wha t protocol to use, and these are equivalent to the "port" in TCP or UDP sockets. It would be nice to have overloads of serviceName / serviceDescription / ServiceProvider which take a QLocale::Language parameter and return the language specific description if one is available. (In practice most services only have a primary language defined) * QBluetoothSocket There are way more errors than ConnectionRefusedError - PageTimeoutError,ServiceNotFoundError for example connectToService() needs overloads which take a QBluetooth::SecurityFlags The client as well as the server can initiate encryption (and this is mandatory for qualification of some bluetooth profiles) The connectToService overloads which takes a uuid or QBluetoothServiceInfo could result in either an RFCOMM or L2CAP socket being opened, so there needs to be some way of querying this after connected. (For example, OBEX can be implemented over both legacy RFCOMM and efficient L2CAP) For L2CAP sockets, you need a way to request an unreliable (flow control mode) connection, the default should be reliable ([enhanced] retransmission mode or basic mode depending on stack capabilities). Unreliable connections are used for isochronous services such as audio. socket descriptors are not ints on symbian - if you hope for that API to be usable to import/export sockets to native code, it will probably only work on bluez backend. Deriving from QIODevice was the right decision for API consistency. * QBluetoothUuid The bool* ok=0 parameters are not very Qt like. I hope a qWarning is printed if conversion fails and ok is null pointer The user can call minimumSize first to know if the conversion will succeed or not. * QL2CapServer and QRfCommServer Consistent with QTcpServer, which is good. Listen has a default port of 0, which presumably means "auto assign a port and find out what was assigned by calling serverPort()" - this needs to be documented. Also need to document what the default address means on a system with multiple bluetooth interfaces (which you imply support for with this API and with QBluetoothLocalDevice::allDevices) You should implement errorString() too, to give debug information when a function fails (as in QTcpServer) * QBluetoothTransfer[*] Needs a lot more work to be useful. Consider how you would handle persistent OBEX connections for profiles such as FTP, PBAP and MAP. More operations are needed such as SETPATH I think these need to be considered before releasing something that only works for limited OPP and may not be easily extensible to other use cases. An OBEX server API is also needed, but could be separate from this client only API. btw, are you using the OS implementations of OBEX? Best Regards, Shane Kearns -- Communications with Accenture or any of its group companies ("Accenture Group") including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with company policy. Accenture Group does not accept service by e-mail of court proceedings, other processes or formal notices of any kind. Accenture means Accenture (UK) Limited (registered number 4757301), Accenture Technology Solutions Limited (registered number 4442596), or Accenture HR Services Limited (registered number 3957974), all registered in England and Wales with registered addresses at 30 Fenchurch Street, London EC3M 3BD, as the case may be. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. _______________________________________________ Qt-mobility-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-mobility-feedback
