Hi Minjung Thanks for your reply, may be I should check meego code, because I can't find any platform service for bluetooth.
> -----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 1:43 PM > To: Zhang, Wen (Sky); [email protected] > Cc: [email protected]; [email protected] > Subject: Re: [Qt-mobility-feedback] TP1.2 bluetooth API > > 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 > _______________________________________________ Qt-mobility-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-mobility-feedback
