Revisit how licenses are stored?

[ararslan]

As the number of supported licenses grows, so will the download size and required disk space for this plugin, since the licenses are currently stored as plain text files in the resources/ directory. As it stands now, that directory is at 288 KB, so this is definitely more of an academic rather than practical concern at this point and it's entirely possible that this will never actually become a problem in practice.

That said, sometimes just thinking about alternatives to things is fun, so here are some potential alternatives to the status quo:

• Don't store any licenses as part of the repository itself. When a user attempts to insert a license for the first time, fetch it via curl or something and then store it on disk so that subsequent accesses are fast and don't require network access.

  • Pros: Minimal disk space required for the plugin itself, only licenses that are used are ever stored
  • Cons: Requires repeated network access

• Bundle all licenses into a compressed archive that's extracted at plugin installation time.

  • Pros: Reduced download size for the plugin
  • Cons: Adding a new license requires recreating the archive, no reduction in total disk space used, potentially complicated to automate self-installation and otherwise a decompression step is forced onto the user

• Continue to store individual licenses in this repository but compress them individually with something like shoco. The individual files are then decompressed in memory for writing but remain compressed on disk.

  • Pros: For shoco in particular, you can train your own compression model, which should actually work well for licenses since they tend to use a similar, limited vocabulary
  • Cons: Contributing a new license requires compressing it before committing, requires additional software unless a decompressor is implemented in VimScript (lol)

The more I think about this, the less likely I think it is that I'll want to pursue any change to how licenses are stored (or at least implementing any of these particular changes). I would however be interested to know if/when a particular facet of this plugin becomes a pain point for users that could be solved by changing the way licenses are stored.

[ypid]

I would go with the first option ("Don't store any licenses as part of the repository itself."). This is how https://reuse.software does it (#8). #8 also covers #10 btw.