Re: [Bluez-devel] [PATCH] Make RemoteName D-BUS method non-blocking

[Marcel Holtmann <marcel@holtmann.org>]

Hi Johan,

> > I am not that big in D-Bus programming, but I think that is how it
> > should work. The failed signal then can contain an error code or we
> > simply use the error method for it.
> 
> Ok. I'll create a new RemoteNameFailed signal which has one byte
> parameter (the status code). Do you want yet another patch against the
> current CVS HEAD, or should I wait for you to commit my previous patch
> and then create a new patch against the new CVS revision?

I only applied the library patch and not your remote name patch. So
please do it against CVS HEAD now.

Doesn't it make sense to use the general error method? We spent so many
time talking about the error definition. Shouldn't we use it?

> > Another thing is that we might wanna have a method where we can request
> > a name from the cache and if not available we request it.
> 
> Maybe this could be done by adding a boolean "use cache" parameter to
> the RemoteName method?

I think using the cache should be default, because the name resolving
always requires a baseband connection and this costs too much to do it
to often. My idea is that we handle all things in background without
putting too much intelligence about names into the client application.
So please come up with ideas what an application really need to now
about names.

> > Besides this we also should keep the extended inquiry in mind. This can
> > deliver us the full name via an inquiry response or at least a short
> > name for a device. So what I see is we have four different types of
> > device names inside our system.
> > 
> > 	- Full device names (up to 248 characters)
> > 	- Short names or inquiry names (up to around 235 at max)
> > 	- Cached names (in generell only up to 248 characters)
> > 	- Alias names (no length requirement)
> > How do deal with them through a nice interface, because all of them can
> > be different.
> 
> I think that the extendend inquiry response names could either be
> handled by adding new parameters to the end of the InquiryResult signal,
> or then by creating a new ExtendendInquiryResult signal. We might want
> to leave the "alias name" feature to be handled by higher SW layers.
> E.g. gnome-bluetooth has some support for storing the alias name under
> the GConf path /system/bluetooth/device/<bd addr>/alias.

I think about renaming the InquiryResult into something more meaningful
like RemoteDevice or something. This signal should include the name from
the extended inquiry or a cached name or an empty string. We might also
include the list of UUIDs and some vendor information. The future is the
extended inquiry and we should plan the D-Bus interface around it. Any
comments?

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