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 not
the useful.

Regards,
Claudio.

On 9/21/05, P. Durante <shackan@gmail.com> 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 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
>