Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate cost of always enabling IOTSA_WITH_PLACEHOLDERS #40

Open
jackjansen opened this issue Jan 4, 2021 · 0 comments
Open

Investigate cost of always enabling IOTSA_WITH_PLACEHOLDERS #40

jackjansen opened this issue Jan 4, 2021 · 0 comments
Assignees

Comments

@jackjansen
Copy link
Contributor

If (and this is a big if) the cost of always enabling IOTSA_WITH_PLACEHOLDERS is not too big (in code size especially, but also runtime efficiency) it may be worthwhile to always enable this.

Then we could have classes IotsaApplication and IotsaMod that would be much simpler (with the current ones renamed to IotsaBaseApplication and IotsaBaseMod although the latter name is taken already).

The new IotsaApplication would automatically contain all auxiliary modules (Battery, Files, FileBackup, FilesUpload, Ota, and maybe also NTP and User/MultiUser), but they would be placeholdered-out if those features were not enabled through IOTSA_WITH_xxxxx.

The new IotsaMod would include support for Rest, COAP and API, again placeholdered-out if disabled.

One huge advantage is that a lot of #ifdefs in user code could go away. So could a lot of boilerplate in the main programs (all the specifications of the standard modules).

It could also make #14 more feasible, because of the unified base module (which would include or not include functionality based on the IOTSA_WITH_xxxx that are used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant