Hi Anderson, On Thu, Apr 3, 2014 at 10:16 PM, Anderson Lizardo <anderson.lizardo@xxxxxxxxxxxxx> wrote: > Hi Lukasz > > On Thu, Apr 3, 2014 at 4:07 PM, Lukasz Rymanowski > <lukasz.rymanowski@xxxxxxxxx> wrote: >> Indeed the only common thing is attribute database as I mention in >> offline email. >> And we are perfectly fine to have this in src/shared/gatt-db.c >> We started in src/gatt.c as this fine anyway contains now only db. >> >> However, I think that bdt_attribure fits us and we want to use it in gatt-db, >> but user of the gatt-db would be use only handle as proposed by Marcin. > > Indeed, moving the GATT DB to src/shared will also mean having a > struct similar to btd_attribute there (but in my RFC it will be > internal as the API will only deal with handles). > >> Actually, also ATT encoding and decoding could be common part. > > I can't find ATT decoding/encoding on the Android HAL headers. Are you > sure this is not handled internally by Android HAL? What I meant is that we have to do ATT encoding/decoding in the daemon. Android is getting only read/write callbacks with value Therefore, code for ATT enc/dec could be common. > >>> - implement proper database "defragmentation". >> >> Since Android does not have way to handle it, we will leave it for future work. > > IMHO this needs at least to be detected and return a proper error. If some Android App will remove GATT service, then given service will be removed from gatt-db. Daemon will send Service Changed to bonded devices and remote device hopefully will refresh their database. Other devices which will want to access missing GATT service will get error on ATT. I think there is nothing wrong that we will have some not used handles in the database or I missing something? > >>> - How attribute permissions are handled? >>> >> What do you mean? > > As I said on the other reply, I could not understand how the > "permissions" parameters should be used in Android. Once you figure > out how to use them, we need to make a generic way to also handle > permissions on Linux. For now I'll just ignore it on the RFC code. > Permissions we will handle in daemon. Meaning, daemon will take care to call android read/write callbacks only if permissions are OK for doing that. > Best Regards, > -- > Anderson Lizardo > http://www.indt.org/?lang=en > INdT - Manaus - Brazil BR Lukasz -- 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
