Query Regarding new Gatt server attribute database

Query Regarding new Gatt server attribute database

[Bharat Bhusan Panda]

Hi All,

We are working on Gatt server implementation, for Tizen framework with BlueZ
5.20 as base.

We have few query on adding new service info to gatt attrib server database,
so that remote gatt client can discover the same.

On Calling "RegisterService" method to org.bluez.GattManager1, after getting
proper data from GattService1, GattCharacteristic1 and GattDescriptor1
interface,
It calls, btd_gatt_add_service(),btd_gatt_add_char() and btd_gatt_add_desc
respectively and updates the local_attribute_db. 
Which should be read and updated, when remote gatt client connects and
starts primary services discovery, but this does not happen, instead it
reads from attrib server db in attrib-server.c.

How can the local_attribute_db in gatt.c, be attached to ATT IO channel, as
it has been done for attrib-server db in src/attrib-server.c?

Thanks
Best Regards,
Bharat

RE: Query Regarding new Gatt server attribute database

[Bharat Bhusan Panda]

Hi All, 

Adding one more query to the same.

As there is no update to attrib server db, from gatt-dbus.c, can we reuse
the APIs here to add service, char and desc values to attrib server db?

>From Gatt Application, if it changes its char/descriptor values, how blueZ
will get to know the same, as there is no propertiesChanged watch set in
bluez?

Is there any plan to update, gatt-dbus.c, or all the functionalities are
moving to src/shared/ ??

It will be helpful, if anyone can clear above doubts :)

Thanks
Best Regards,
Bharat 
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Bharat Bhusan Panda
> Sent: Wednesday, August 27, 2014 8:53 PM
> To: linux-bluetooth@vger.kernel.org
> Cc: bharat.panda@samsung.com
> Subject: Query Regarding new Gatt server attribute database
> 
> Hi All,
> 
> We are working on Gatt server implementation, for Tizen framework with
> BlueZ
> 5.20 as base.
> 
> We have few query on adding new service info to gatt attrib server
database,
> so that remote gatt client can discover the same.
> 
> On Calling "RegisterService" method to org.bluez.GattManager1, after
> getting proper data from GattService1, GattCharacteristic1 and
> GattDescriptor1 interface, It calls,
> btd_gatt_add_service(),btd_gatt_add_char() and btd_gatt_add_desc
> respectively and updates the local_attribute_db.
> Which should be read and updated, when remote gatt client connects and
> starts primary services discovery, but this does not happen, instead it
reads
> from attrib server db in attrib-server.c.
> 
> How can the local_attribute_db in gatt.c, be attached to ATT IO channel,
as it
> has been done for attrib-server db in src/attrib-server.c?
> 
> Thanks
> Best Regards,
> Bharat
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
in
> the body of a message to majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

Re: Query Regarding new Gatt server attribute database

[Arman Uguray]

Hi Bharat,

> Is there any plan to update, gatt-dbus.c, or all the functionalities are
> moving to src/shared/ ??
>

Others can comment more but I don't think there is (or there will be)
any work to maintain/develop what's in src/gatt-dbus and src/gatt, at
least not the way that they're currently built. The plan right now is
to move all core functionality into src/shared and then (re)build most
of the daemon's D-Bus bits using the new shared code.

I don't know how well the existing GATT D-Bus server stuff works at
the moment but I was under the impression that none of that's
feature-complete. Others can comment more.

Cheers,
Arman

RE: Query Regarding new Gatt server attribute database

[Bharat Bhusan Panda]

Hi Arman,

> > Is there any plan to update, gatt-dbus.c, or all the functionalities
> > are moving to src/shared/ ??
> >
> 
> Others can comment more but I don't think there is (or there will be) any
> work to maintain/develop what's in src/gatt-dbus and src/gatt, at least not
> the way that they're currently built. The plan right now is to move all core
> functionality into src/shared and then (re)build most of the daemon's D-Bus
> bits using the new shared code.
Thanks for your reply, 
One more thing to ask,The Gatt methods listed in gatt-api.txt "RegisterService" and "UnregisterService" and other GATT service interfaces, these are currently handled in gatt-dbus.c.
Is there any plan to move this to src/share and, what would be the design then?
Currently in att/share there are only gatt client code placed. If there is a plan to move server functionalities to src/share, Can I continue and implement the same?
 
> 
> I don't know how well the existing GATT D-Bus server stuff works at the
> moment but I was under the impression that none of that's feature-
> complete. Others can comment more.

Yes, this is not working currently, as the current code does not update the core attrib server db, it's storing in a local service list.

Thanks
Best Regards,
Bharat

Re: Query Regarding new Gatt server attribute database

[Arman Uguray]

Hi Bharat,

> One more thing to ask,The Gatt methods listed in gatt-api.txt "RegisterService" and "UnregisterService" and other GATT service interfaces, these are currently handled in gatt-dbus.c.
> Is there any plan to move this to src/share and, what would be the design then?
> Currently in att/share there are only gatt client code placed. If there is a plan to move server functionalities to src/share, Can I continue and implement the same?

Yes, the current plan is to implement a shared/gatt-server (just like
we have a shared/gatt-client) and implement the server code using
that. The actual structure of the code needs some discussion and
design which I'm planning to get going in the next couple of weeks.

shared/gatt-server will act as the attribute database and handle
everything regarding ATT protocol translation so most of the data
structures internal to gatt-dbus will likely go away. We might
actually end up changing the way the D-Bus API code itself is
structured (maybe splitting it into src/gatt-client and
src/gatt-server) but that needs some design and discussion as well.
All of this will happen in the following months and I prefer not to
rush any of it so that we get all of this right.


>> I don't know how well the existing GATT D-Bus server stuff works at the
>> moment but I was under the impression that none of that's feature-
>> complete. Others can comment more.
>
> Yes, this is not working currently, as the current code does not update the core attrib server db, it's storing in a local service list.
>

I'm not super familiar with the GATT server D-Bus code the way it
currently is. As I said, I don't want to rush the shared code
implementation though I understand that you may not want to be blocked
on our progress/plans. Once we've got the design of shared/gatt-server
down, I will come up with a set of TODOs for server which you can help
with. The more people we have on board the faster this'll get done.

Cheers,
Arman