Haketilo

Current schema for handling custom page resources (currently only scripts) has the concept of 3 types of objects:

1. Scripts - A script has a unique name and text contents (or url+hash for fetching the text contents).
2. Bags - A bag has a unique name and a list of subresources that can be other bags or scripts.
3. Pages - A "page" has a unique pattern specifying to which URLs it applies, a whitelist boolean flag and a payload (either a script or a bag) to inject into an actual opened page.

After some time I came to think this schema is suboptimal. Before I start changing anything I'd like to gather some feedback, though. The issues I see are:

Pages are not flexible enough¶

Right now a "page" is basically a pattern with some settings applied to it. In practice, however, it would be useful to be able to specify multiple pattern-payload mappings for a single site. Let's assume there is a site like fansofbloat.com. This site can have different things under https://fansofbloat.com/about https://fansofbloat.com/contact and https://fansofbloat.com/user/<name-of-user> and maybe even https://<name-of-project>.fansofbloat.com/details. Now, let's assume there's some Mr Cooldev who develops libre script replacements, custom styling and enhancements for fansofbloat.com. He manages to deliver his custom stuff for all of the URLs mentioned, with the same kind of changes, although using slightly different sets of javascript libraries under different kinds of URLs. Unfortunately, because of the way pages are specified right now, Mr Cooldev's work has to be split into several page objects and a typical user who wants to enable all Mr Cooldev's fixes for fansofbloat.com has to enable several pages in the settings which is inconvenient.

Additionally, if Miss Greatskill decides to make her own fixes for all or part of fansofbloat.com, their patterns collide with those used by Mr Cooldev. Sure, nobody would be using those 2 sets of fixes simultaneously. However, it would be nice to be able to store them all in the settings, just not having them all enabled at once.

I believe we should make page object able to store multiple pattern->payload mappings. It should also have a unique name, just as script and bag have.

Having bags and scripts as separate objects is not very convenient¶

The current approach is flexible enough, but is a bit weird and having to pass information whether some component is a script or a bag is irritating. When we package software for a distro, the equivalence of bag would be, for example, a package of a library. Such package has its files and dependencies as completely separate objects. Also, files and packages live on different levels of abstraction.

I think we should embrace a schema similar to that one. We could have dependencies and files (be they scripts or later maybe also CSS files or some arbitrary data files) listed as 2 different properties of a bag. A payload would have to be a bag and not a script. Scripts would no longer be able to live independently of bags and would not have their own tab in the settings page.

WDYT?