Can the specific HCI package be part of the target definition instead of the app? That way apps could remain HCI-transport agnostic. Just a thought.
thanks, aditi > On Mar 24, 2016, at 11:58 PM, will sanfilippo <[email protected]> wrote: > > Yes, that is what I was proposing. I understand your annoyance; not sure if > the app is the best place myself but it seems to be a reasonable place for > now. > > Will > >> On Mar 24, 2016, at 10:10 AM, Christopher Collins <[email protected]> >> wrote: >> >> On Wed, Mar 23, 2016 at 05:08:37PM -0700, will sanfilippo wrote: >> [...] >> >> To summarize my understanding of your proposal (please let me know if I >> got anything wrong!): >> >> 1. Create several independent HCI packages in the net/nimble directory. >> >>> net/nimble/hci_spi >>> net/nimble/hci_combined >>> net/nimble/hci_uart >> >> 2. Each HCI package exports the "ble_hci" API in its pkg.yml. >> >> # net/nimble/hci_spi/pkg.yml >> pkg.apis: ble_hci >> >> 3. Both net/nimble/host and net/nimble/controller require the "ble"hci" >> API in their pkg.yml files. >> >> # net/nimble/host/pkg.yml >> pkg.req_apis: ble_hci >> >> 4. The app specifies the hard dependency on a specific HCI package. >> >> # apps/myapp/pkg.yml >> pkg.deps: @apache-mynewt-core/net/nimble/hci_spi >> >> I like it. There is one annoyance, though: it is too bad that the app >> has to depend on a specific HCI package. Using bletiny as an example, >> it would be nice if this app could be HCI-transport-agnostic. However, >> some piece of code has to initialize the specific HCI package being >> used, and it makes sense that this would happen in the app, so I am not >> sure this is an issue. It might be worthwhile to think a bit about how >> we might solve this issue cleanly. The only solutions I can think of >> add too much complexity to justify, in my opinion. >> >> Thanks, >> Chris >
