Hi Arman, >> I am pretty open on how many steps we want to take at a time or what we want to do later. What I know for sure is that I >> want to rid of GIOChannel and BtIO usage and GLib. > > I agree with everything you described and I think a clean GLib-free > implementation that can be shared among Linux and Android code is the > way to go. My only concern is that a D-Bus GATT client API is much > needed for Chromium and I'm concerned that the big overhaul involved > in removing BtIO and GLib is going to take too long. > > So my question is this: how open would you be for an initial GATT > client API that uses the existing code in attrib/* internally? I'm > thinking of something very similar to how android/gatt.c has been > implemented so far. So what I have in mind is: > > - The bt_gatt structure you mentioned, lives in src/shared/gatt.* > and internally uses GAttrib, etc. The code is D-Bus free and could be > used by the GATT client code in android/gatt as well. > - D-Bus code added to src/gatt-dbus.* to expose client objects. > This code talks to src/shared/gatt.*. > - src/device.* and profiles modified to use the new API with no > explicit GIOChannel usage. I have no problem in doing this in parallel and take smaller or different steps. My main point is that everybody knows where we need to go in the long term. > What I'm suggesting is basically to make the daemon use the new API > first and implement the new API with the existing GLib based code so > that we have at least some implementation to work with for Chromium > (and we isolate GLib usage to one place as far as GATT is concerned), > and THEN implement bt_gatt, bt_att etc. the proper way. Is this > something that you would be open to upstreaming? My primary concern is > simply the amount of time it will take to implement a new ATT/GATT > endpoint but if you believe that we should absolutely do it the right > way the first time around then it's not the end of the world. Go ahead with it. Internal refactoring is simple. Just plan to have unit tests included that check will ensure that all changes you make are tested. We did this for AVDTP, AVRCP and now MCAP for our refactoring to make code shareable between Android and upstream. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
