add dbus api to set class of device?

add dbus api to set class of device?

[Tim Renouf]

Hi all

I am putting a JSR82 implementation on an Android device that uses
BlueZ, accessing BlueZ via the dbus api.

JSR82 has an API where you can set service class bits for a particular
service you have registered. So the JSR82 implementation needs to be
able to set the class of device in some way. I would like to add a dbus
method to do this, and I'd like to know the opinion of BlueZ developers
on this:

1. Is this a reasonable thing to do and submit a patch for ?

2. What would be a good approach, out of the following (or any other
possibility I have missed) ?

2a. Add a dbus method to set service class bits for a registered
service. This would set a new field in sdp_record_t. The existing
function update_adapter_svclass_list in sdpd-service.c would read this
new field in every service record when determining the service class
bits to set. The setting gets cleared automatically when the service is
removed. This seems like the cleanest solution.

2b. Add a dbus method to set service class bits, or all device class
bits, globally for the dbus connection. There would have to be a list of
dbus connections, each storing the connection's requested class.
manager_update_svc would scan that list. The setting gets cleared
automatically when the dbus connection is lost.

2c. Add a dbus method to set service class bits, or all device class
bits, globally. This can just call the BlueZ internal method directly.
The problems with this are (i) it doesn't work if multiple apps are
trying to use it; (ii) the setting gets lost next time a service gets
registered or removed, so the app needs to be aware of this and reapply
its setting, and (iii) the setting remains if the app exits or crashes
without removing it.

I note that Bluecove-on-BlueZ does not implement this, therefore it
fails the same conformance test that I am looking at.

Thanks.

-tpr

Re: add dbus api to set class of device?

[Marcel Holtmann]

Hi Tim,

> I am putting a JSR82 implementation on an Android device that uses
> BlueZ, accessing BlueZ via the dbus api.
> 
> JSR82 has an API where you can set service class bits for a particular
> service you have registered. So the JSR82 implementation needs to be
> able to set the class of device in some way. I would like to add a dbus
> method to do this, and I'd like to know the opinion of BlueZ developers
> on this:

I did mention before that JSR82 is the most stupid Bluetooth API that I
have seen so far, didn't I? Personally I wouldn't even bother with JSR82
and give up right away. It is really a pointless API.

In BlueZ the services bits of the class of device settings are modified
dynamically based on the registered SDP service records. So you don't
have to do anything. Just register the right SDP service record with the
proper UUID and it will take care of this automatically.

Regards

Marcel

Re: add dbus api to set class of device?

[Tim Renouf]

Hi Marcel

> I did mention before that JSR82 is the most stupid Bluetooth API that I
> have seen so far, didn't I? Personally I wouldn't even bother with JSR82
> and give up right away. It is really a pointless API.

Unfortunately I have to bother with it as our customers are device
manufacturers who are willing to pay for MIDP with JSR82 support. :-(

> In BlueZ the services bits of the class of device settings are modified
> dynamically based on the registered SDP service records. So you don't
> have to do anything. Just register the right SDP service record with the
> proper UUID and it will take care of this automatically.

Yes, I saw that in update_adapter_svclass_list. I guess the problem is
that JSR82 lets an app decide to set the "wrong" bit, and the
conformance tests test that functionality.

So if I did a patch along the lines I was suggesting, and submitted it
here, would it be rejected on the grounds that it is not needed for any
"sensible" functionality ?

Thanks.

-tpr

Re: add dbus api to set class of device?

[Marcel Holtmann]

Hi Tim,

> > I did mention before that JSR82 is the most stupid Bluetooth API that I
> > have seen so far, didn't I? Personally I wouldn't even bother with JSR82
> > and give up right away. It is really a pointless API.
> 
> Unfortunately I have to bother with it as our customers are device
> manufacturers who are willing to pay for MIDP with JSR82 support. :-(
> 
> > In BlueZ the services bits of the class of device settings are modified
> > dynamically based on the registered SDP service records. So you don't
> > have to do anything. Just register the right SDP service record with the
> > proper UUID and it will take care of this automatically.
> 
> Yes, I saw that in update_adapter_svclass_list. I guess the problem is
> that JSR82 lets an app decide to set the "wrong" bit, and the
> conformance tests test that functionality.

fake the conformance test with just adding and removing the right SDP
records ;)

As I said, JSR82 is the most stupid API I have ever seen. It seems these
guys had no clue about Bluetooth when specifying it. And this is besides
that fact that every application has to implement SDP parsing by itself.

> So if I did a patch along the lines I was suggesting, and submitted it
> here, would it be rejected on the grounds that it is not needed for any
> "sensible" functionality ?

I think you just answered this by yourself. I makes no sense to add such
an API since it has the exact problems that you mentioned earlier. Once
you have two applications this gets messy. And it will not work properly
at all. So for us such an extra API will introduce problems instead of
solving anything.

Regards

Marcel