Hi Zhang, Mobility is relying on the platform service. There is no daemon process that Mobility provides.
Regards, Min -----Original Message----- From: ext Zhang, Wen (Sky) [mailto:[email protected]] Sent: Monday, 17 January 2011 3:34 PM To: Shin Minjung (Nokia-MS-Qt/Brisbane); [email protected] Cc: Stanley-Jones Andrew (Nokia-MS/Brisbane); [email protected] Subject: RE: TP1.2 bluetooth API Hi Minjun After study the bluetooth API code, and I want to know qt-mobility have a service or daemo for bluetooth which run on the background to receive the signal from blueZ? Thanks! > -----Original Message----- > From: > [email protected]. > com > [mailto:qt-mobility-feedback-bounces+wen.zhang=windriver.com@q > t.nokia.com] On Behalf Of [email protected] > Sent: Monday, January 17, 2011 12:48 PM > To: [email protected] > Cc: [email protected]; [email protected] > Subject: Re: [Qt-mobility-feedback] TP1.2 bluetooth API > > 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 > _______________________________________________ Qt-mobility-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-mobility-feedback
