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
--
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
