Hello Luiz, Thanks for looking at my proposal. > On Sep 6, 2017, at 10:14 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > > Your implementation is not really LE specific, in fact it will cause > the clients to believe they connected over LE if the MTU appears, > besides with cross transport pairing and dual mode topology this has > to work either way or then we have to disable GATT completely on > BR/EDR. Of course, yes, my previous implementation is not appropriate for this new API. There's differences of opinion about what the API should be, and I'm proposing a revised API to address feedback from yourself and others. If there's consensus that my revised API is appropriate, I'll then propose an implementation. > > Also, the AcquireWrite and AcquireNotify should fulfil most of the use > cases where GATT is used just as transport to another protocol, is > that what you are intending to do? I'm merely conforming to an existing protocol, which requires me to only publish GATT attributes which are length <= MTU - 3. This is because we can't depend on Long Read and Long Write support from BTLE clients. In cases where a larger MTU has been negotiated, I need to take advantage of it, for optimal throughput. I didn't design the protocol, but it's out there in the wild, and I need to support it. > > Having an API just for a very specific use case that in the future may > actually disappear with OSes adopting L2CAP CoC is not very nice. We already have several LE-specific APIs (e.g. LEAdvertisingManager), so I don't understand this objection. BTLE GATT will be with us essentially forever. Also, I've proposed marking this dbus property as experimental, so I don't see the problem with trying it out. It addresses a real need. Best, Jonah-- 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
