Return-Path: Message-ID: From: Claudio Takahasi To: bluez-devel@lists.sourceforge.net Subject: Re: [Bluez-devel] hcid D-Bus patch In-Reply-To: <9307f5f205092106191197c374@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_834_9015266.1127310775478" References: <1127292701.495.11.camel@localhost.localdomain> <9307f5f205092106191197c374@mail.gmail.com> Sender: bluez-devel-admin@lists.sourceforge.net Errors-To: bluez-devel-admin@lists.sourceforge.net Reply-To: bluez-devel@lists.sourceforge.net List-Unsubscribe: , List-Id: BlueZ development List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Sep 2005 10:52:55 -0300 ------=_Part_834_9015266.1127310775478 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Paul, An ERROR may have any arguments, but if the first argument is a STRING(error message). Therefore, the signature should be sq (string+uint16). In my opinion the error message string is not relevant, the client applications can use it or not. If we consider internationalization, this string will no= t the useful. Regards, Claudio. On 9/21/05, P. Durante wrote: > > Hi, > > > org.bluez.hci.error.Failed /* here we can add the bluetooth error code > */ > > Just an idea, keep it simple, if you give the clients just the > bluetooth error code they'll have to decode its meaning using > something like strerror( bt_error( error_code )) every time they make > a request, quite boring, even worse, bt_error is bluez-specific and if > the client wants to use something like that in a language which is not > C, they should grab the bluetooth specification write their own > function which tells what each error code means... > > or > > since dbus errors consist of error_name + error_message you could put > something meaningful in the error_message, and eventually append an > additional field with the error code to the message as well ( if the > application wants to treat some error codes in a particular way ) this > seems ok with the dbus specification which only says (if I remember > correctly) that if the first field in an error message is of type > 'string' that string will be treated as the error message, and doesn't > say anything about additional fields. > > regards > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your ver= y > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Bluez-devel mailing list > Bluez-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bluez-devel > ------=_Part_834_9015266.1127310775478 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Paul,

An ERROR may have any arguments, but if the first argument is a
STRING(error message). Therefore, the signature should be sq (string+uint16= ).
In my opinion the error message string is not relevant, the client applicat= ions
can use it or not. If we consider internationalization, this string will no= t
the useful.

Regards,
Claudio.

On 9/21/05, P. Durante <sha= ckan@gmail.com> wrote:
Hi,

>  org.bluez.hci.error.Failed  /* here we= can add the bluetooth error code */

Just an idea, keep it simple, i= f you give the clients just the
bluetooth error code they'll have to dec= ode its meaning using
something like strerror( bt_error( error_code )) every time they makea request, quite boring, even worse, bt_error is bluez-specific and ifthe client wants to use something like that in a language which is not
C, they should grab the bluetooth specification write their own
func= tion which tells what each error code means...

or

since dbus = errors consist of error_name + error_message you could put
something mea= ningful in the error_message, and eventually append an
additional field with the error code to the message as well ( if theapplication wants to treat some error codes in a particular way ) this
= seems ok with the dbus specification which only says (if I remember
correctly) that if the first field in an error message is of type
'strin= g' that string will be treated as the error message, and doesn't
say any= thing about additional fields.

regards


------------------= -------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with = Apache's Geronimo App Server.
Download it for free - -and be entered to = win a 42" plasma tv or your very
own Sony(tm)PSP.  Click = here to play:=20 http://sourceforge.net/gero= nimo.php
_______________________________________________
Bluez-de= vel mailing list
Bl= uez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

------=_Part_834_9015266.1127310775478-- ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel