Feature #48
Load default_setting.json using XMLHttpRequest
0%
Description
I believe XMLHttpRequest can also be used to fetch extension's own files. After fetching the default settings file, we could use JSON.parse() on it. That would reduce the complexity of our build script
History
Updated by jahoti about 2 years ago
(Responding here as the other issue is now resolved.)
Btw, I am considering maintaining old build.sh alongside the new build.html.
Plus, IMHO, changing to use XMLHttpRequest would be a good idea in case of the JS build system, too
That makes sense now- I had been assuming the intention was to use XMLHttpRequest in the build process somehow, which (unless I'm again mistaken) is not the case?
Updated by jahoti about 2 years ago
Preferrably preceded by: https://hachettebugs.koszko.org/issues/59
Updated by koszko about 2 years ago
Depends. We can make this issue obsolete and completely move bundled settings to the repo.
Or, after moving most of stuff to the repo we can select some of it we consider the most useful and of highest quality and bundle it in addition to it being available from there
Updated by jahoti about 2 years ago
Definitely the latter; moving fixes to the repository first would only be in order to have the build script(s) download fixes from there, rather than including the code in default_setting.json.
On the other hand, that could prevent offline builds; IDK.
Updated by koszko about 2 years ago
On the other hand, that could prevent offline builds; IDK.
Not necessarily.
I think reference to how Arch packaging works might be useful here. Arch PKGBUILD script used to create packages allows the packager to program more or less the following stages:
- fetching of sources (done declaratively, by providing the relevant URLs).
- validating of sources (also declaratively, by providing checksums or allowed PGP keys)
- configuration
- build
- installation to a directory
The contents of that directory then ends up in the actual package.
Packaging for other distros follows a similar pattern, although Arch seems to have the least "magic" added around it. Actually, Debian source packages are tarballs with everything already downloaded (like after steps 1 and 2 that were already performed by a packager) and possibly patched for dfsg. So, the fact we need to download some more sources doesn't mean the build itself has to be online. We can still make releases in the form of tarballs with everything already downloaded.
Also, the practice of linking one git repo from another could be useful here.
Updated by jahoti about 2 years ago
Not necessarily.
I think reference to how Arch packaging works might be useful here. Arch PKGBUILD script used to create packages allows the packager to program more or less the following stages:
- fetching of sources (done declaratively, by providing the relevant URLs).
- validating of sources (also declaratively, by providing checksums or allowed PGP keys)
- configuration
- build
- installation to a directory
The contents of that directory then ends up in the actual package.
Packaging for other distros follows a similar pattern, although Arch seems to have the least "magic" added around it. Actually, Debian source packages are tarballs with everything already downloaded (like after steps 1 and 2 that were already performed by a packager) and possibly patched for dfsg. So, the fact we need to download some more sources doesn't mean the build itself has to be online. We can still make releases in the form of tarballs with everything already downloaded.
Ah- I see! Such a system seems sensible, and if we package for distros it'll inevitably occur in some form or another anyway.
Also, the practice of linking one git repo from another could be useful here.
How do you mean?
Updated by koszko about 2 years ago
Also, the practice of linking one git repo from another could be useful here.
How do you mean?
Updated by koszko over 1 year ago
- Status changed from New to Rejected
We're moving to IndexedDB. Default settings will now be accessed from database initialization function, not from background/main.js. IndxedDB initialization happens in a transaction which does not allow arbitrary asynchronous operations to be performed. This makes asynchronous XHR not applicable. We'd have to either use synchronous XHR or put the default settings in a file. In this case I'd rather do the second. I will be moving the default settings to exports_init.js. In the future we might try boosting the imports system with a directive like IMPORTJSON which could make the build system simpler