[Bluez-devel] Bluez DBUS API usuability regarding end user experience

[Bluez-devel] Bluez DBUS API usuability regarding end user experience

[Fabien Chevalier]

[-- Attachment #1: Type: text/plain, Size: 2536 bytes --]


Marcel,

I have a (kind of) formal request to ask to the Bluez project.

I'm basically trying to use the Bluez API to design a user friendly 
device that will have bluetooth functionnality.
Speeking of a user friendly device, i'm thinking of two things i wanna have:
   - the end user bluetooth feature should work most of the time, which
means it will have to be robust and not throw errors most of the time.
   - When something goes wrong, the end user should only be presented 
with error messages he can understand and actually act upon. If the 
message is too cryptic, then a generic placeholder would be use instead 
of a low level message. One of the first non cryptic messages i think of 
would be a "Device unreachable : please check your bluetooth device is 
powered on" message :-)

I've done a quick review of hcid an audio service code, and did some 
testing too. What i've found is:
  - for hcid case: the closed match i found is the 
org.audio.bluez.ConnectionAttemptFailed exception. This one seems to be 
raised when the L2CAP connection fails. But it is not specific on the
failure cause ( i think what i'm looking for is EHOSTDOWN posix error 
code, please correct me if i'm wrong ;-) )
  - for Audio service the case is different. Sink object Connect() dbus 
call would fail with org.bluez.audio.Error.Failed while the Headset 
object Connect() dbus call would fail with 
org.bluez.audio.Error.ConnectFailed. Those two are not even consistent :-(
headset.c code looks even a bit hackish, as it tryes to regenerate the 
lost EHOSTDOWN error code by hand :

if (dbus_error_has_name(&derr,						 
"org.bluez.Error.ConnectionAttemptFailed"))
	err_connect_failed(device->conn, c->msg,
					strerror(EHOSTDOWN));

My point of view is that this common case of error should be clearly 
identified and sent up to the application.

What i would like to do is propose a patch that would:
   - Define org.bluez.Error.DeviceUnreachable exception for hcid. This 
would be fired each time a connect on an l2cap socket would return 
EHOSTDOWN.
   - Define org.bluez.Error.Audio.DeviceUnreachable for use by the audio 
service. This one would be sent by the Headset and Sink objects instead 
of the org.bluez.audio.Error.Failed and 
org.bluez.audio.Error.ConnectFailed when the l2cap/rfcomm/sco connect() 
code returns EHOSTDOWN.

Marcel, would you agree this is the right way to proceed ? Would you be 
willing to accept patches that move the code in that direction ?
( I mean : shall i start coding now ? ;-) )

Regards,

Fabien


[-- Attachment #2: fchevalier.vcf --]
[-- Type: text/x-vcard, Size: 253 bytes --]

begin:vcard
fn:Fabien CHEVALIER
n:CHEVALIER;Fabien
org:SILICOM
adr:;;4 rue de Jouanet; RENNES ATALANTE;;35700;FRANCE
email;internet:fchevalier@silicom.fr
title:Software & Studies Engineer
tel;work:+33 (0) 2 99 84 17 17
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluez DBUS API usuability regarding end user experience

[Marcel Holtmann]

Hi Fabien,

> I have a (kind of) formal request to ask to the Bluez project.
> 
> I'm basically trying to use the Bluez API to design a user friendly 
> device that will have bluetooth functionnality.
> Speeking of a user friendly device, i'm thinking of two things i wanna have:
>    - the end user bluetooth feature should work most of the time, which
> means it will have to be robust and not throw errors most of the time.
>    - When something goes wrong, the end user should only be presented 
> with error messages he can understand and actually act upon. If the 
> message is too cryptic, then a generic placeholder would be use instead 
> of a low level message. One of the first non cryptic messages i think of 
> would be a "Device unreachable : please check your bluetooth device is 
> powered on" message :-)

feel free to improve the error messages. We haven't spend enough time
with them yet. There were other issues that needed to be addressed
first. Also the error support should made generic and reside in common/.
So if you wanna work on it, send patches.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluez DBUS API usuability regarding end user experience

[Fabien Chevalier]

Marcel Holtmann wrote:
> Hi Fabien,
> 
>> I have a (kind of) formal request to ask to the Bluez project.
>>
>> I'm basically trying to use the Bluez API to design a user friendly 
>> device that will have bluetooth functionnality.
>> Speeking of a user friendly device, i'm thinking of two things i wanna have:
>>    - the end user bluetooth feature should work most of the time, which
>> means it will have to be robust and not throw errors most of the time.
>>    - When something goes wrong, the end user should only be presented 
>> with error messages he can understand and actually act upon. If the 
>> message is too cryptic, then a generic placeholder would be use instead 
>> of a low level message. One of the first non cryptic messages i think of 
>> would be a "Device unreachable : please check your bluetooth device is 
>> powered on" message :-)
> 
> feel free to improve the error messages. We haven't spend enough time
> with them yet. There were other issues that needed to be addressed
> first. Also the error support should made generic and reside in common/.
> So if you wanna work on it, send patches.

Hi Marcel,

I didn't though error handling was that bad. :-(
And... yes i volunteer to work on this, so i'm gonna start to work on 
generic error support in common/. :-)

Cheers,

Fabien


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel