+1 ... raw buffer plus helpers offers the best of both worlds imho. Le mar. 24 janv. 2017 à 21:40, will sanfilippo <[email protected]> a écrit :
> 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 > > > >
