Return-Path: MIME-Version: 1.0 Sender: armansito@google.com In-Reply-To: <8B6D3E26-762A-490C-9E33-A8E8357C97F5@holtmann.org> References: <8B6D3E26-762A-490C-9E33-A8E8357C97F5@holtmann.org> Date: Tue, 8 Apr 2014 15:11:22 -0700 Message-ID: Subject: Re: Removing GAttrib. From: Arman Uguray To: Marcel Holtmann Cc: Claudio Takahasi , BlueZ development , lukasz.rymanowski@tieto.com Content-Type: text/plain; charset=UTF-8 List-ID: Hi Marcel, > 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. 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. Cheers, Arman