From: Johan Hedberg <johan.hedberg@nokia.com>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] [PATCH] Make RemoteName D-BUS method non-blocking
Date: Thu, 20 Oct 2005 12:50:35 +0300 [thread overview]
Message-ID: <20051020095035.GA26910@localhost.localdomain> (raw)
In-Reply-To: <1129798977.2241.35.camel@blade>
On Thu, Oct 20, 2005, Marcel Holtmann wrote:
> 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?
> 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?
> 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.
Johan
-------------------------------------------------------
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
next prev parent reply other threads:[~2005-10-20 9:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-19 14:07 [Bluez-devel] [PATCH] Make RemoteName D-BUS method non-blocking Johan Hedberg
2005-10-19 15:03 ` P. Durante
2005-10-19 17:45 ` Johan Hedberg
2005-10-19 22:58 ` Marcel Holtmann
2005-10-20 7:05 ` Johan Hedberg
2005-10-20 7:52 ` Marcel Holtmann
2005-10-20 8:37 ` Johan Hedberg
2005-10-20 9:02 ` Marcel Holtmann
2005-10-20 9:50 ` Johan Hedberg [this message]
2005-10-20 10:16 ` Marcel Holtmann
2005-10-20 11:21 ` Johan Hedberg
2005-10-20 13:37 ` Johan Hedberg
2005-10-22 12:58 ` Marcel Holtmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051020095035.GA26910@localhost.localdomain \
--to=johan.hedberg@nokia.com \
--cc=bluez-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox