Hi Marcel,
On Thu, Aug 19, 2021 at 7:57 AM Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
>
> Hi Luiz,
>
> > This adds Experimental property which indicates what experimental
> > features are currently enabled.
> > ---
> > doc/adapter-api.txt | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
> > index 464434a81..13e904425 100644
> > --- a/doc/adapter-api.txt
> > +++ b/doc/adapter-api.txt
> > @@ -335,3 +335,8 @@ Properties string Address [readonly]
> > "peripheral": Supports the peripheral role.
> > "central-peripheral": Supports both roles
> > concurrently.
> > +
> > + array{string} Experimental [readonly, optional]
> > +
> > + List of 128-bit UUIDs that represents the experimental
> > + features currently enabled.
>
> I wonder if this is the best name.
>
> Do we care about just the enabled experimental features or the overall supported experimental features as well. And please keep in mind that we also have per-adapter vs global experimental features. So we should distinguish here as well.
This is per-adapter and I guess the global one would could exposed on
all adapters since we don't have a global object, or perhaps you are
suggesting to use / for that?
> We also need to document that this property is only available if bluetoothd is started with -E and otherwise this property is omitted.
Will add it.
> My proposal would be to at least name it ExperimentalSupport or ExperimentalFeatures to give us a path to nicely extend it if needed.
Sure, I do wonder if we should make it writable as well, so
applications can enable/disable experimental features themselves? Or
perhaps that is going too far as to enable unstable code by
application, it would only work when -E is given thought which would
enable everything anyway but I was thinking on having -E optionally
take a list of UUIDs so one could enable just certain features
instead.
> Regards
>
> Marcel
>
--
Luiz Augusto von Dentz
