Project

General

Profile

Feature #48

Load default_setting.json using XMLHttpRequest

Added by koszko 5 months ago. Updated about 13 hours ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Start date:
07/06/2021
Due date:
% Done:

0%

Estimated time:

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

#1

Updated by jahoti 5 months 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?

#2

Updated by jahoti 5 months ago

#3

Updated by koszko 5 months 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

#4

Updated by jahoti 5 months 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.

#5

Updated by koszko 4 months 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:

  1. fetching of sources (done declaratively, by providing the relevant URLs).
  2. validating of sources (also declaratively, by providing checksums or allowed PGP keys)
  3. configuration
  4. build
  5. 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.

#6

Updated by jahoti 4 months 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?

#7

Updated by koszko 4 months ago

Also, the practice of linking one git repo from another could be useful here.

How do you mean?

https://git-scm.com/book/en/v2/Git-Tools-Submodules

#8

Updated by koszko 10 days ago

  • Parent task deleted (#44)
#9

Updated by koszko about 13 hours 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

Also available in: Atom PDF