Re: [PATCH] gatt api V2

Hi Marcel,

either we can convert GAttrib to use bt_att as underlying layer or we end=

 up having to do the conversion all at once.

Actually an initial starting point here could be to see how much we actua=

lly need to rely on GIOChannel for GATT. Maybe it is worth while to move th=
e GIOChannel into GAttrib itself and just create it from the file descripto=
r. Once GIOChannel is an internal detail, it might be easy to switch over t=
o struct io. All things that can be explored and need to be done eventually=
 anyway.

Yeah, actually this may not be so bad. We might be able to turn
GAttrib into a simple wrapper around a bt_att initially. I was
actually a bit hesitant to modify GAttrib at first, since I don't want
to break the Android code but I'll follow whichever route is easier in
the end.

I think the GIOChannel comes from bt_io_connect and just get passed to
g_attrib_new and for the purposes of GAttrib it is already mostly an
internal detail (afaict). We could change it so that GAttrib maybe
takes in a bt_att in its constructor (or the raw fd directly). I'll
start playing with this eventually and see how it goes.

Cheers,
Arman