Re: GATT Dbus API on BlueZ - attirbute-api.txt modifications

Hi Chen,

On Mon, Oct 31, 2011 at 3:19 AM, Ganir, Chen [off-list ref] wrote:

quoted

Ok, I see a trend here :) We are now discussing about the current
Generic API implementation and not about doc/attribute-api.txt nor
your patch right? Ideally the .txt doc should always reflect the .c
code, but currently it is not the case. I suggest we get back to the
API discussion, then we can fix the code to behave like documented. Is
that ok?

Unless I misunderstood, the doc/attribute-api.txt describes the generic API? Or is it called somewhat else? I'm talking about the DBUS interface which enables external GATT Clients to be implemented on top of DBUS.

Yes, it is the so called "generic API", although this unofficial alias
is too generic for my taste :).

quoted

If it was meant to be some cache, I think it could be mentioned on the
API document. The reason it is only read once is implementation
limitation, not the API.

Ok. I understand this now. You were responding as if you were totally aware of the problematic current implementation, and this is why it was so strange and difficult to understand your arguments. Now that we agree on the fact that the property "Value" Should always be read, Can we also make sure that the Value property should be omitted from the "get_properties" response, in case there is no connection?

Note I did not actually agree the Value (as a property) should always
be read over-the-air, I was explaining it is not a cache at all, but a
"read once" value. For me it is a sort of limitation, because you
can't use it in all use cases (the same way I explained that ReadValue
method is not ok in all other use cases as well).

I would rather go with Ajay's suggestion for now, and in short term
(as your ReadValue implementation evolves) we drop Value if we indeed
see it as redundant. As long as we don't declare this API stable
(which it is not currently), I see no problem postponing the decision
of whether keeping Value or not.

What about writing the value? Should we allow the user to set the value with either Write request/Write Command/Write signed or do we really want to keep that internal (like read/read blob) ?

Again, If I were to implement it, I would stick with the core spec
requirements, and checking Characteristic Properties and the link
encryption status for deciding which operation to use. But if you
really think it is useful to allow D-Bus clients "break" spec
requirements some times, you can provide this control. This particular
detail is not my main concern :).

quoted

Again, you are assuming a Core spec's "client" as a D-Bus client. This
may mean we have not been on the same page since long :)

Why do you think it will not work ? the DBUS for me is just a transparent transport for GATT operations. It should not have too much logic in it. The code mentioned above is also a bit problematic for me, since it hides some of the GATT functionality, and I'm not sure I'm still comfortable with this kind of encapsulation. Why do you think allowing the user to set the security level correctly before reading, or after getting the ATT_ECODE_INSUFF_ENC is wrong ?

If you allow "application A" to set seclevel by itself, it will affect
any other applications (on the same host) which share the same
connection, but are working with other services. Now some may say this
is not common, but it is, if you are able to see IOP results on BT SIG
mailing lists , you can see some interesting combinations of profiles.

On the other hand, if BlueZ takes care of this, it will do what is
best to keep all apps happy.

What do we benefit from hiding so much from the DBUS user who implements the profile? As I said before, I would rather let the DBUS client implementing the profile as much flexibility and control, to prevent future major changes to API when we realize we forgot something important.

And here I can argue that, on the other hand, giving "full control"
means you need to keep that "complete" API for a long time, and if you
think you made a mistake allowing applications to do that much, you
cannot go back. Extending the API , on the other hand, is easier.

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil