Changes to add-on system - documentation? about addon-list

[mrstegeman]

• What is the manifest file for? Should both package.json and manifest.json be maintained? Should the manifest.json file be in the file list inside package.sh? It seems manifest.json no longer stores a list of files associated with the add-on?

We've decided to move away from the npm package.json format to a manifest.json format inspired by WebExtensions. As we've been adding new types of add-ons (extensions), this move made sense.

In order to support older gateway versions, you should include both package.json and manifest.json in your package for now. 0.10 will support both formats as an interim step, to allow developers time to move to the new format.

Your manifest.json does need to have a checksum, along with every other file in the package (except for SHA256SUMS itself).

You can read more about packaging and the manifest.json format here.

• How should data now be stored? Are the settings still stored in the Gateway database, but should the persistence files now move from the config folder to another folder within the add-on folder?

Correct. The user profile directory and the gateway's database were getting quite littered by add-ons, so we've decided to have add-ons move their data into separate folders, i.e. ~/.mozilla-iot/data/<addon-id>. In the future, these individual directories (and the add-ons themselves) may have their own UID/GID, so this will allow for better isolation.

The config settings are still stored in the gateway's database and are still available through the Database class in the gateway-addon libraries.

• Will the UI extension adapter type also gain a Python option/example?

The APIs are essentially identical between the Node.js and Python add-ons (other than camelCase vs. snake_case naming), so the example-extension should translate very easily. Let me know if you need help.

• How could/should I change, for example, the Candle Manager add-on so that it will become a UX extending add-on in the next version? Can add-ons be all three types at the same time? For example, the Voco add-on is both a notifier and adapter, but could perhaps also have a UI. Is that possible?

An add-on can be any combination of adapter/notifier/extension. Right now, the extension API on the UI side is pretty basic. You can add your own menu entry and are given a page to draw to. On the back-end, you can add your own REST API handlers to do more advanced things. If there are additional UI APIs that would be helpful, please open issues so that we can look into it.

• Will UI extending add-ons still need to deal with copy-pasting authorization codes if they want to have access to all the things? I se some mention of the internal API being available now, but I'm not sure what that all means/could mean.

Yes, for now. We'll hopefully come up with an easier way of doing this soon, but we still have a lot of other things to tackle for 0.10. You can see our roadmap here.

• How/when could I prepare and pre-test the new system before Gateway 0.10 launches? Could I compile the beta myself? Or is there a test image available to prepare add-ons for the transition?

You can always build and run the gateway yourself. Instructions are in the README.

• Any other things I should be aware of? :-)

Probably!

Sorry for the long list. It's just that with the exhibit coming up I have to manage time well, and would like to prepare the add-on as early as possible.

The Candle smart home project will be launched on the 19th of October. Is there a tentative date for when version 0.10 of the WebThings Gateway will be released? I would love to show the more integrated version of the add-ons at Dutch Design Week.

Not sure yet, probably toward the end of October. You're always welcome to run the master branch, as it's typically fairly stable.

Thanks for the great explanations!

It seems the "turn package.json into manifest.json" python script doesn't copy the file list? Should I add it still? If so, where exactly? I'll see if I can find an example somewhere.

I guess add-ons that work on 0.9 and 0.10 should temporarily create the ~/.mozilla-iot/data/ directory if it doesn't exist yet? Or would it be possible to provide two .tgz files, one 'old' one, and a new one for 0.10 and above?

the example-extension should translate very easily. Let me know if you need help.

Yes please! An example would be very helpful.

[mrstegeman]

It seems the "turn package.json into manifest.json" python script doesn't copy the file list? Should I add it still? If so, where exactly? I'll see if I can find an example somewhere.

The files array is no longer a part of the manifest. Instead, we require every single file in the package to be in the SHA256SUMS file.

I guess add-ons that work on 0.9 and 0.10 should temporarily create the ~/.mozilla-iot/data/ directory if it doesn't exist yet? Or would it be possible to provide two .tgz files, one 'old' one, and a new one for 0.10 and above?

Yes, you should just create that directory yourself for now. Please wait to start creating add-ons specific to gateway versions. The new manifest has that ability, but you should wait to use it until we no longer support the package.json format (probably 0.11).

the example-extension should translate very easily. Let me know if you need help.

Yes please! An example would be very helpful.

I converted the example-extension to Python for a demo: https://github.com/mrstegeman/example-extension/tree/python

[flatsiedatsie]

Thank you! Looking into it now.