I am not sure I have any intelligent comments on this, but that has never stopped me from commenting in the past, so…
I think a byte buffer interface is fine as long as you have helper functions to create that buffer. Having folks have to figure out how to create an advertisement without any helper functions would be a bad idea (imho). I am not sure I completely understand your example re:Tx Power Level. Would this field still get added by the host or would there be a helper function that a developer could call to add the Tx Power Level field to the advertisement? > On Jan 24, 2017, at 11:45 AM, Christopher Collins <[email protected]> wrote: > > Hello all, > > I've mentioned this before - I really don't care for the advertising > data API that we ended up with: > http://mynewt.apache.org/latest/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_fields/ > > I think we should change this API now before the 1.0 release. I was > wondering what others think. > > The current API is high-level and is relatively easy to use, but > requires a lot of code space and RAM. I think a function which just > takes a raw byte buffer (or mbuf) would be much better. Then, there > could be a helper function which converts an instance of `struct > ble_hs_adv_fields` to a raw byte buffer. > > A simple peripheral that always advertises the same data shouldn't be > burdened with the ble_hs_adv_fields API. > > There is actually a rationale as to why the API is the way it is today. > There are a few fields in the advertisement data that the host can be > configured to fill in automatically: > * Flags (contains advertising type). > * TX Power Level > > I figured it would be safer if these values got calculated when > advertising is initiated. This is impractical if the host were handed a > byte buffer rather than a series of fields. > > Under the new proposal, the application would need to specify the > correct advertising type when building the byte buffer, and the tx power > level would be queried before the advertising procedure is actually > started. I don't think this will be a problem in practice, and I think > the benefits in code size and RAM usage outweigh the API burden. > > All thoughts welcome. > > Thanks, > Chris
