Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200401221434.12185-1-sonnysasaka@chromium.org>
 <ACB5D50F-BAD5-435A-AD1C-58A16878C310@holtmann.org> <CAOxioNnBq3J_F63RNHZfQzKOcwSmVy2igJ6zCfgBH+zcL1kaCw@mail.gmail.com>
 <CABBYNZKnoUoA=01o1fZL25=Pvmq-L8VZehPB80p9fErm=GF+Gg@mail.gmail.com>
In-Reply-To: <CABBYNZKnoUoA=01o1fZL25=Pvmq-L8VZehPB80p9fErm=GF+Gg@mail.gmail.com>
From:   Sonny Sasaka <sonnysasaka@chromium.org>
Date:   Thu, 9 Apr 2020 14:08:31 -0700
Message-ID: <CAO271mnx6pQD9S94kMzHHbt8JGOmNy-C3bS7jSGXoSD_kZD7XA@mail.gmail.com>
Subject: Re: [PATCH 1/5] D-Bus API changes for managing SDP records
To:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc:     Marcel Holtmann <marcel@holtmann.org>,
        Bluez mailing list <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Thanks for the feedback, Luiz. We will explore the ways you all suggested.

On Thu, Apr 9, 2020 at 11:35 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Sonny,
>
> On Thu, Apr 9, 2020 at 11:28 AM Sonny Sasaka <sonnysasaka@chromium.org> w=
rote:
> >
> > Hi Marcel,
> >
> > This was needed to support emulation of Android apps's Bluetooth API
> > on top of BlueZ. Android expects to be able to access the SDP database
> > of a remote device via its HAL interface
> > (https://android.googlesource.com/platform/system/bt/+/master/include/h=
ardware/bt_sdp.h#38).
>
> I suppose you could read the cache directly, though there is no
> guarantee that we won't change the format of that, btw I suppose
> services handled by the daemon should not be exposed to the Android
> side otherwise you may have conflicts so going with Profile interface
> is probably the way to go, but you will need to know the UUIDs that
> would be handled by Android.
>
> > Thanks for the feedback, we will revisit this and see if a redesign
> > based on your suggestion is possible.
> >
> > On Thu, Apr 9, 2020 at 11:05 AM Marcel Holtmann <marcel@holtmann.org> w=
rote:
> > >
> > > Hi Sonny,
> > >
> > > > This defines the DBus API that we'll use with BlueZ to create, remo=
ve
> > > > and get service records.
> > > > ---
> > > > doc/adapter-api.txt | 46 ++++++++++++++++++++++++++++++++++++++++++=
+++
> > > > doc/device-api.txt  | 37 ++++++++++++++++++++++++++++++++++++
> > > > 2 files changed, 83 insertions(+)
> > > >
> > > > diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
> > > > index acae032d9..6e4c37fc9 100644
> > > > --- a/doc/adapter-api.txt
> > > > +++ b/doc/adapter-api.txt
> > > > @@ -204,6 +204,52 @@ Methods          void StartDiscovery()
> > > >                                        org.bluez.Error.NotReady
> > > >                                        org.bluez.Error.Failed
> > > >
> > > > +             uint32 CreateServiceRecord(dict record)
> > > > +
> > > > +                     This method creates an entry with the local S=
DP server
> > > > +                     for this adapter for the specified record. Th=
is method
> > > > +                     will only create the SDP record and not start=
 listening
> > > > +                     on any ports. It is up to the caller of the m=
ethod to
> > > > +                     ensure the validity of the service record. Th=
is record
> > > > +                     will not be parsed for any validation but wil=
l instead
> > > > +                     directly be inserted into the local SDP serve=
r=E2=80=99s
> > > > +                     records.
> > > > +
> > > > +                     The return value from this method will be the=
 32 bit
> > > > +                     handle for the created service record.
> > > > +
> > > > +                     The record dictionary will have dictionary en=
tries of
> > > > +                     the format: {id : (type, size, value)}, where=
,
> > > > +
> > > > +                     uint16 id:      The 16 bit attribute ID for a=
n
> > > > +                                     attribute.
> > > > +                     uint8 type:     This will contain the type of=
 the
> > > > +                                     attribute value. Attribute ty=
pe values
> > > > +                                     are defined in the Bluetooth =
spec in
> > > > +                                     Volume 3, Part B, 3.2.
> > > > +                     uint32 size:    This is the size of the attri=
bute
> > > > +                                     value.
> > > > +                     variant value:  This will contain the attribu=
te value
> > > > +                                     for a given attribute_id. Thi=
s variant
> > > > +                                     can either contain a primitiv=
e type, or
> > > > +                                     if type is SEQUENCE, an array=
 of struct
> > > > +                                     of the signature (type, size,=
 value).
> > > > +
> > > > +                     Possible errors: org.bluez.Error.NotReady
> > > > +                                      org.bluez.Error.AlreadyExist=
s
> > > > +                                      org.bluez.Error.Failed
> > > > +                                      org.bluez.Error.InvalidArgum=
ents
> > > > +
> > > > +             void RemoveServiceRecord(uint32 handle)
> > > > +
> > > > +                     This method removes the SDP record with the g=
iven
> > > > +                     handle from the local SDP server.
> > > > +
> > > > +                     Possible errors: org.bluez.Error.NotReady
> > > > +                                      org.bluez.Error.DoesNotExist
> > > > +                                      org.bluez.Error.Failed
> > > > +                                      org.bluez.Error.InvalidArgum=
ents
> > > > +
> > >
> > > so when design the BlueZ 5.x APIs, we on purpose didn=E2=80=99t do th=
is. You are suppose to use doc/profile-api.txt for these kind of things.
> > >
> > > I am not in favor of dangling SDP records where we have no lifetime g=
uarantee of the service behind it.
> > >
> > > If you look at profiles/iap/main.c then you see how you could write a=
 vendor profile just as easily. That one is the skeleton for iOS accessory =
protocol over Bluetooth.
> > >
> > > > Properties    string Address [readonly]
> > > >
> > > >                       The Bluetooth device address.
> > > > diff --git a/doc/device-api.txt b/doc/device-api.txt
> > > > index ceb68d2f6..e8f2c670d 100644
> > > > --- a/doc/device-api.txt
> > > > +++ b/doc/device-api.txt
> > > > @@ -120,6 +120,43 @@ Methods          void Connect()
> > > >                       Possible errors: org.bluez.Error.DoesNotExist
> > > >                                        org.bluez.Error.Failed
> > > >
> > > > +             array{array{dict}} GetServiceRecords()
> > > > +
> > > > +                     This method returns the complete service reco=
rds of all
> > > > +                     discovered BR/EDR services of the connected d=
evice till
> > > > +                     now. The return value will be an array of an =
array of
> > > > +                     dictionary entries. Each nested array of dict=
ionary
> > > > +                     entries will contain one service record. Each=
 pair in
> > > > +                     the returned dictionary entries will represen=
t an
> > > > +                     attribute in the service record.
> > > > +
> > > > +                     The dictionary entries in the returned array =
of entries
> > > > +                     will be of the format: {id : (type, size, val=
ue)} where,
> > > > +
> > > > +                     uint16 id:      The 16 bit attribute ID for a=
n
> > > > +                                     attribute.
> > > > +                     uint8 type:     This will contain the type of=
 the
> > > > +                                     attribute value. Attribute ty=
pe values
> > > > +                                     are defined in the Bluetooth =
spec in
> > > > +                                     Volume 3, Part B, 3.2.
> > > > +                     uint32 size:    This is the size of the attri=
bute
> > > > +                                     value.
> > > > +                     variant value:  This will contain the attribu=
te value
> > > > +                                     for a given attribute_id. Thi=
s variant
> > > > +                                     can either contain a primitiv=
e type, or
> > > > +                                     if type is SEQUENCE, an array=
 of struct
> > > > +                                     of the signature (type, size,=
 value).
> > > > +
> > > > +                     Since the service record contains the service=
 UUID and
> > > > +                     name, these fields do not need to be given se=
parately.
> > > > +                     This method should be called after the Servic=
eResolved
> > > > +                     property for this object has been set to true=
 otherwise
> > > > +                     it may return a partial or stale cached list.
> > > > +
> > > > +                     Possible errors: org.bluez.Error.NotReady
> > > > +                                      org.bluez.Error.NotConnected
> > > > +                                      org.bluez.Error.Failed
> > > > +
> > >
> > > These two things are not related and do not belong in the same patch.=
 However what is your goal behind this API since even here we tried not to =
give raw SDP to the application. It is all baked into the Profile API.
> > >
> > > Regards
> > >
> > > Marcel
> > >
>
>
>
> --
> Luiz Augusto von Dentz