Return-Path: Message-ID: From: Claudio Takahasi To: bluez-devel@lists.sourceforge.net Subject: Re: [Bluez-devel] hcid D-Bus patch In-Reply-To: <1127398647.5344.24.camel@blade> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8734_11503243.1127407865649" References: <1127292701.495.11.camel@localhost.localdomain> <1127398647.5344.24.camel@blade> 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: Thu, 22 Sep 2005 13:51:05 -0300 ------=_Part_8734_11503243.1127407865649 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Marcel, Regarding the shared code I will analize the shared functions and move to the common directory. The D-Bus error is a message created based on a received message. There are 4 message types: 1. method call message 2. method reply message 3. error message 4. signal First of all you have to understand the difference bus name, path and interface. Read http://dbus.freedesktop.org/doc/dbus-faq.html#id2778454 for more information. There is a FAQ with this topic. In my opinion is better associate a "method" as a "service" this analogy is more clear. They use method just to pass the idea of object oriented programming. Where the object is the instance of a class that provides several services and the method is just one service(function). In a usage scenario, a client will request a service using a method call message. The result (method reply or error message) will be received only by the requestor because the reply or the error are created based on the received message header infos. It's possible send a method reply containing an argument with an error code and ignore the usage of error messages. But this is not a good programming practise because there are D-Bus functions to work with error messages. These functions make possible compare the error NAME without extract the other arguments embedded in the message. After this discussion I would suggest the following structure: >>> Message Error Names: org.bluez.EFailed org.bluez.ENoMemory /* open to more error names */ >>>org.bluez.EFailed This error message will have the signature(string+uint16+uint32). Where the first argument is the error description. The second is the error class and the third is the error code. The error class can be system error, D-Bus error or HCI errors. This structure mane possible return to the app clients any kind of error. System error includes socket error, IO, ENODEV... D-Bus error includes no service, no connection, security error and no method found. HCI errors are listed in the bluetooth specification. Maybe someone could ask why not bind the error to the profiles/bluez daemon like org.bluez.hci.EFailed, org.bluez.sdp.EFailed, org.bluez.pan.EFailed. Add an extra information(like the profile) in the message error doesn't add relevant information because the error messages will be receive= d only by the requestor. Regards, Claudio On 9/22/05, Marcel Holtmann wrote: > > Hi Claudio, > > > I will analize our comments. > > > > service_table_t and the function create_error_reply_message will be > > shared by other profiles(pan, hid, rfcomm, ...) > > this the reason to put in the dbus-internal.h file. > > if this is shared code then I like to have it in the common/ toplevel > directory. We should create the files dbus.[ch] and then use them from > there. > > > Regarding the Bluetooth error codes, we can add the code in the D-Bus > > error messages as a argument. My proposal > > is use a standard like this: > > > > org.bluez.hci.error.UnknowMethod > > org.bluez.hci.error.WrongSignature > > org.bluez.hci.error.WrongParam > > org.bluez.hci.error.Failed /* here we can add the bluetooth error > > code */ > > org.bluez.hci.error.Busy > > org.bluez.hci.error.NoDevFound > > > > I will send a new path soon. > > So a D-Bus error is always a method? I would simply use a general error > with an identifier number. Help me out here to understand what is the > best way to represent the errors. > > Regards > > Marcel > > > > > ------------------------------------------------------- > 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_8734_11503243.1127407865649 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Marcel,

Regarding the shared code I will analize the shared functions
and move to the common directory.


The D-Bus error is a message created based on a received message.
There are 4 message types:
1. method call message
2. method reply message
3. error message
4. signal

First of all you have to understand the difference bus name, path and
interface. Read http://dbus.freedesktop.org/doc/dbus-faq.html#id2778454
for more information. There is a FAQ with this topic.

In my opinion is better associate a "method" as a "service&q= uot; this analogy
is more clear. They use method just to pass the idea of object oriented
programming. Where the object is the instance of a class that provides
several services and the method is just one service(function).

In a usage scenario, a client will request a service using a method
call message. The result (method reply or error message) will be
received only by the requestor because the reply or the error are
created based on the received message header infos.
It's possible send a method reply containing an argument with an error
code and ignore the usage of error messages. But this is not a good
programming practise because there are D-Bus functions to work with
error messages. These functions make possible compare the error NAME
without extract the other arguments embedded in the message.

After this discussion I would suggest the following structure:

>>> Message Error Names:
org.bluez.EFailed
org.bluez.ENoMemory
/* open to more error names */

>>>org.bluez.EFailed
This error message will have the signature(string+uint16+uint32).
Where the first argument is the error description. The second is
the error class and the third is the error code.
The error class can be system error, D-Bus error or HCI errors.
This structure mane possible return to the app clients any kind of
error. System error includes socket error, IO, ENODEV... D-Bus error
includes no service, no connection, security error and no method found.
HCI errors are listed in the bluetooth specification.

Maybe someone could ask why not bind the error to the profiles/bluez daemon=
like org.bluez.hci.EFailed, org.bluez.sdp.EFailed, org.bluez.pan.EFailed. <= br> Add an extra information(like the profile) in the message error
doesn't add relevant information because the error messages will be receive= d
only by the requestor.

Regards,
Claudio


On 9/22/05, Marcel Holtmann <marc= el@holtmann.org> wrote:
Hi Claudio,

> I will analize our comments.
>
> servic= e_table_t and the function create_error_reply_message will be
> share= d by other profiles(pan, hid, rfcomm, ...)
> this the reason to put i= n the=20 dbus-internal.h file.

if this is shared code then I like to have it = in the common/ toplevel
directory. We should create the files dbus.[ch] = and then use them from
there.

> Regarding the Bluetooth error = codes, we can add the code in the D-Bus
> error messages as a argument. My proposal
> is use a standar= d like this:
>
> org.bluez.hci.error.UnknowMethod
> org.b= luez.hci.error.WrongSignature
> org.bluez.hci.error.WrongParam
> org.bluez.hci.error.Failed  /* here we can add the bluetooth= error
> code */
> org.bluez.hci.error.Busy
> org.bluez.h= ci.error.NoDevFound
>
> I will send a new path soon.

So = a D-Bus error is always a method? I would simply use a general error
with an identifier number. Help me out here to understand what is thebest way to represent the errors.

Regards

Marcel



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's G= eronimo App Server.
Download it for free - -and be entered to win a 42&q= uot; plasma tv or your very
own Sony(tm)PSP.  Click here to pl= ay: http://sourceforge.net/geronimo.php
________________________________= _______________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

------=_Part_8734_11503243.1127407865649-- ------------------------------------------------------- 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