linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] [DBUS] remote name patch
Date: Mon, 23 Jan 2006 21:14:11 +0100	[thread overview]
Message-ID: <1138047251.3750.6.camel@localhost.localdomain> (raw)
In-Reply-To: <e1effdeb0601231054q2a3e1ec1q6f0e2c90a48c05e3@mail.gmail.com>

Hi Claudio,

> > Regarding the name, we might simply say the hcid/bluetoothd always sends
> > a remote name signal if something changes. So it might get the short
> > name from the extended inquiry first and after that it receives the full
> > remote name. We can also always send the cached name and we update that
> > name on every service discovery, because then it is at zero cost.
> 
> The remote name is triggered by D-Bus clients. hcid/bluetoothd doesn't
> request the remote when the inquiry finishes. For EIR, are you
> suggesting send the "InquiryResult" signal followed by a "RemoteName"?

this sounds like a sane and backward compatible way of doing this.

> If we send the "RemoteName" with the short name, probably D-Bus
> clients will not request the RemoteName to retrieve the complete name.
> D-Bus clients should not distinguish short/complete name.

It is up to hcid/bluetoothd to update the remote when the client
requests a service discovery.

> Regarding the RemoteName request service signature. Do you agree with
> my initial proprosal? (see the first e-mail sent: have an alternative
> to force send the HCI remote name and another using the cache)

No. We don't need any extra stuff. The client asks for a name and we
give them a name. That's it and all the rest is implementation specific
to hcid/bluetoothd.

> > So we have one device name. This maybe a cached, a remote or a shortened
> > name. The application doesn't really have to care and it gets updates as
> > soon as hcid/bluetoothd knows them.
> >
> > Besides the device name, we should implement an alias name. This name is
> > associated with the BD_ADDR and can be changed by the user if he/she
> > doesn't like the device name. Implementing this alias through the D-Bus
> > interface makes it available for all applications and we can store the
> > aliases in /var/lib/bluetooth/<bdaddr>/aliases.
> 
> When a client requests a RemoteName, which value should be returned?
> The value stored in the aliases file or the value stored in the names
> file? Or are you suggesting create a property 
> "GetProperty("alias")/SetProperty("alias", "value")?

When they request the remote name or device name, then they get the
device name that is valid at the moment. This will maybe a cached name,
but that doesn't matter. If hcid/bluetoothd knows better they will send
out a remote name signal to tell them.

The alias name is totally different and independent. It is application
choice to use the alias name or not. If the alias name is empty they can
use the remote/device name.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2006-01-23 20:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-20 18:37 [Bluez-devel] [DBUS] remote name patch Claudio Takahasi
2006-01-21  1:48 ` Marcel Holtmann
2006-01-23 16:33   ` Claudio Takahasi
2006-01-23 17:08     ` Marcel Holtmann
2006-01-23 18:54       ` Claudio Takahasi
2006-01-23 20:14         ` Marcel Holtmann [this message]
2006-01-26 14:09           ` Claudio Takahasi
2006-01-26 18:03             ` Marcel Holtmann
2006-02-09 13:55               ` Claudio Takahasi
2006-02-09 15:56                 ` 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=1138047251.3750.6.camel@localhost.localdomain \
    --to=marcel@holtmann.org \
    --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;
as well as URLs for NNTP newsgroup(s).