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 received
only by the requestor.

Regards,
Claudio


On 9/22/05, Marcel Holtmann <marcel@holtmann.org> 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 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
>