RE: [PATCH] gatt api V2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi arman, 
> >> > This patch focus on implementing the Gatt DBus API defined in
> >> > gatt-api.txt
> >> discussed in mailist latestly. It implement all the DBus property and
> >> method except for array{object} of characteristics and descriptors.
> >> Through our internal test, patche work well. I would like to contribute this
> featrue for bluez upstream.
> >> This first patch is just an implementation, maybe not very closely
> >> suitable for design or put in the right file. It would be OK to modify to make more
> sense.
> >> > Arman, Marcel, would you like to review the patch and give some
> >> > suggestion
> >> for the patch? It would be great honor for me to contribute little to bluez.
> >>
> 
> Thank you for your patch. The current desire is to migrate all daemon code that uses
> attrib/* for GATT/ATT over to the new utilities in shared/ (gatt-client, att,
> gatt-helpers, etc.). In the end it's up to the maintainers but can we hold off on
> implementing the D-Bus API until the shared code is ready and just do it once the
> right way using bt_gatt_client? There are enough GAttrib dependencies inside the
> daemon code that adding more now will just become a bigger burden in the future.
> 
> I recently added a set of items to the top-level TODO file regarding the new
> GATT/ATT stack; I can talk to you more about tackling the items there.
> 
> Otherwise, if this is blocking people and everyone prefers to have a working GATT
> D-Bus API sooner than that, then I suggest not putting all of the code in src/device.c.
> You should probably abstract that away in a separate module (such as a
> src/gatt-client) and have device.c initialize it. Also, please break this down into
> multiple smaller patches as Luiz suggested.

I have noticed that you are focusing on the Gatt shared library development in maillist 
latestly. And there is always a question in mind that no opportunity to ask you , why we
replace old GATT/ATT by new Gatt shared library? 

According to your advice , I saw the gatt TODO list items including gatt-api.txt part.
Of course, new Gatt DBus API will based on shared/gatt-client. But I believe most logical
would be common except for API from shared/gatt-client.

There is no problem holding on until the shared code is ready, we can use old base and internal
patch to transition.

I saw a lot of TODO List in GATT/ATT part, and gatt-api.txt base on new shared library. So I will
pay more attention to shared library code. Sometimes I am not sure your work plan which items
will do first, which not. So if any help I can do or wrong patches I submitted, just talk to me, 
I would appreciate it.

Thanks
Chaojie Gu
��.n��������+%������w��{.n�����{����^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux