Copyright © https://mongoose-os.com

Mongoose OS Forum

frame

Contribute your work to the Mongoose OS community

SergeySergey Dublin, Ireland
edited June 8 in Mongoose OS

Are your working on some project that others might be interested in?
Using some specific hardware not yet listed on https://github.com/mongoose-os-libs ?

Contribute your work, let others know and use it, please follow https://mongoose-os.com/docs/core_components/apps.html#contribute-app
We'll add it under your authorship, Apache 2 license, to https://github.com/mongoose-os-libs / https://github.com/mongoose-os-apps
Everybody who clicks on "import app" or "import lib" in the GUI, will see it.

Thank you!

Comments

  • I appreciate how this is coming together and getting more modular with the option to include the "pieces" one needs in their projects, but I have a few things I'm still unclear on.

    Libs

    How would you suggest importing libraries like these?
    * IRremote (esp8266)
    * RC-Switch

    APIs:

    Do you think any of these should implement RPC endpoints, or just provide js-wrappers?

    In general, should anything with a js-wrapper have a corresponding RPC endpoint/api? (like the onewire stuff now, compared to i2c which has RPC endpoints ...)

    Updating/Maint:

    • As changes to imported libraries are made (upstream) how do we do updates (from the perspective of the mongoose-lib author/maintainer)?
    • Once those updates are made to the repository (mongoose-os-libs/*), how do those changes get to users?
    • Will the users need to fetch/rebase those "imported" libs? Or will this be automatic (when editing/building/flashing)?
    • Is there going to be some lib versioning, or tagging in the repos?
    • Will the libs get testing/CI integration? Will they be (re)built as changes happen to their dependancies?

    Thanks in advance,
    Scott

  • SergeySergey Dublin, Ireland

    Greetings Scott!

    1. Libraries such as https://github.com/markszabo/IRremoteESP8266 are big enough, so it might not be feasible to just copy/paste them. Choices are:

      • Copy-paste. Still an option (which also adds some level of stability and independence, but could be suboptimal if the target repo is fast moving)
      • Use an undocumented "module" feature, where you can reference an existing GitHub project. See https://github.com/mongoose-os-libs/mjs/blob/master/mos.yml#L18-L19 - here, an mjs lib is using another github project, a vanilla JS engine: https://github.com/cesanta/mjs. So essentially, an mjs lib is a Mongoose OS wrapper around mjs engine.
    2. Do you think any of these should implement RPC endpoints, or just provide js-wrappers? I anticipate a library to provide C/C++ and optionally a JS API, which will allow people to prototype fast. If one fancies remote management, an RPC service can be added as a separate lib rpc-service-WHATEVER - like https://github.com/mongoose-os-libs/rpc-service-fs that adds and RPC service for the device filesystem.
      Said that, maybe it might be possible to make RPC services "automatic" by "marking" API functions, and Mongoose OS can do the magic in a background to expose such a function via the RPC. Maybe. We did not yet think about it.

    3. As changes to imported libraries are made (upstream) how do we do updates (from the perspective of the mongoose-lib author/maintainer)? We collect all libs/apps under the GitHub org. Each lib or app is a GitHub repo. We'll just grant management rights to the contributor for the corresponding repos.

    4. Once those updates are made to the repository (mongoose-os-libs/*), how do those changes get to users? When a user builds an app, mos fetches all libs locally, and pulls them on each build. So unless a user makes local modifications, libs are automatically updated. Dirty libs, however, stop being updated, so this case is up to the user.

    5. Will the users need to fetch/rebase those "imported" libs? Or will this be automatic (when editing/building/flashing)? I think (4) addresses that

    6. Is there going to be some lib versioning, or tagging in the repos? Yes, using standard GitHub mechanisms, but how would one specify required versions - we did not yet design it. Currently, pulling master branches is fine, but that will change. Suggestions are welcome.
    7. Will the libs get testing/CI integration? Will they be (re)built as changes happen to their dependancies? Yes, we are adding everything under our internal CI - including arduino drivers. We have a bunch of devices with attached sensors, etc. We just started to add sensor - specific tests , so we expect at this initial stage some bugs, or plain "dont work" situations.
Sign In or Register to comment.