From: "José Antonio Santos Cadenas" <santoscadenas@gmail.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH] Notify to device drivers when the SDP records change
Date: Tue, 3 Aug 2010 14:33:31 +0200 [thread overview]
Message-ID: <201008031433.31891.santoscadenas@gmail.com> (raw)
In-Reply-To: <AANLkTin9WnU0v2NqS5cAjRxyhipJCBYX0=KWponiCk14@mail.gmail.com>
Hi,
El Tuesday 03 August 2010 13:42:15 Luiz Augusto von Dentz escribió:
> Hi,
>
> On Tue, Aug 3, 2010 at 12:12 PM, José Antonio Santos Cadenas
>
> <santoscadenas@gmail.com> wrote:
> > The different with a2dp is that the application will decide the end point
> > to connect to, because there can be more than one matching the source.
> > This end point is represented by a path that is passed to the
> > HealthAgent when is discovered. If the remote record changes it is
> > possible that new end points are available so the application needs
> > something to discover the available end points. That is why I think that
> > we need something like this.
>
> I guess we already suggest you guys to take a look in the
> MediaEndpoint interface, which can be found here:
>
> http://gitorious.org/~vudentz/bluez/vudentzs-clone/commit/2af3d2821f0aaafae
> 12be10522c82dea6a701688.patch
>
> It doesn't expose the remote endpoints it basically do the best
> matching, if the application requesting the connection has local
> endpoint they have priority, and then the 'agent' or in case of audio
> the endpoint will be notified with the remote endpoint capabilities.
>
> Also while looking the health API it seems you guys missed a very
> important point, HealthAgent only knows about the remote services
> since there is no signal for announcing a new HealthApplication nor
> the application knows the about HealthService, so the only way make
> this to work is that the HealthApplication and HealthAgent leaves in
> the same process but this defeats the point of having them separated.
> So either we have the applications and services being announced to
> everyone and then anyone can do the matching or we don't announce them
> at all and make bluetoothd do the matching itself, I guess the latter
> is better so we don't have to split the logic in many place (with
> potential code duplication + bugs).
>
> Another important thing is that dbus introspection does not have any
> way to notify changes, so it really need to be signal to notify
> applications about new services.
Can we have an IRC session to talk about the API and continuing this
discussion? I think that this thread is changing too much from its original
topic.
Regards.
next prev parent reply other threads:[~2010-08-03 12:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-26 7:55 Notification of SDP changes to device drivers Jose Antonio Santos Cadenas
2010-07-26 7:55 ` [PATCH] Notify to device drivers when the SDP records change Jose Antonio Santos Cadenas
2010-08-02 14:39 ` Luiz Augusto von Dentz
2010-08-03 7:30 ` José Antonio Santos Cadenas
2010-08-03 9:00 ` Luiz Augusto von Dentz
2010-08-03 9:12 ` José Antonio Santos Cadenas
2010-08-03 11:42 ` Luiz Augusto von Dentz
2010-08-03 12:33 ` José Antonio Santos Cadenas [this message]
2010-08-03 12:43 ` José Antonio Santos Cadenas
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=201008031433.31891.santoscadenas@gmail.com \
--to=santoscadenas@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.