On 10/4/05, Claudio Takahasi <cktakahasi@gmail.com> wrote:

Hi Marcel,

Your suggestions were done!
Regarding service_table_t, if we remove it, the logic will be based on "if"and "else", see the HAL message filter function. In my opinion service_table_t is more clear.

If you think that is really necessary remove the error handling and the service_table_t I can do it in the next patch.

Regards,
Claudio.

On 10/3/05, Marcel Holtmann <marcel@holtmann.org > wrote:
Hi Claudio,

> I kept some log information, if you want remove it I can send another
> patch. The error code definition was included. I am using "hciX" in
> the path name until we receive a answer from dbus list. Services under
> the path /org/bluez/Devices weren't implemented yet.
>
> Is there other changes in this patch?

this thing looks quite good, but now we need to clean up some other
parts of your constants and function naming. And please try to keep the
BlueZ/kernel coding style.

The overall BLUEZ_DBUS prefix looks like a good idea at the beginning,
but I think we don't need it at all. So this should be enough:

#define DEVICE_PATH             "/org/bluez/Device"
#define DEVICE_INTERFACE        "org.bluez.Device"

#define MANAGER_PATH            "/org/bluez/Manager"
#define MANAGER_INTERFACE       "org.bluez.Manager"

Please also stop to shortcut some names. For example DFT for DEFAULT.
Simple write the full name, because then it is easy to read this code.

The other thing is that I don't like the difference between *_REQ and
*_SIG in the names/constants. Please don't use them.

Also please don't include any RFCOMM, PAN, HID etc. related things,
because they are not important right now and they make my life of
merging the initial step into better D-Bus a lot harder.

For the error part we will use org.bluez.Error and not EFailed or
anything like this. Since all the error stuff is currently not used, I
don't think it is a good idea to add it to the initial patch. Looking at
HAL the use of org.bluez.NoSuchDevice, etc. seems to make sense, too.

Do we really need that service_table_t thingy now? I think we should
start without it.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

--
---------------------------------------------------------

Claudio Takahasi
Nokia's Institute of Technology - INdT
claudio.takahasi@indt.org.br