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
