Importing your data folder, a module (as a folder or as a single zip) would still do the same thing. The current plan is that it would check 4 things against the database :
- type (system or module?)
- manifest url
If all 4 match an existing system/module in the database, then it would suggest to the user to use that instead, so no need to upload and no need to use quota. If a user has a modified module, they’d need to either change the name/version/manifest url, or say “no, use the one I uploaded” during import.
I am currently trying to deal with the case (for the migration) of multiple people having the same module with the same version, but with different files, since often module devs just link to the master github, so downloading it at a different moment could yield a different content.
I think I’ll need to just download the latest of that version and simply use that.
What I want to avoid is someone submitting a zip/manifest which could be malicious and affecting others, so I’d be the only one to check the manifest urls before approving a module/system to the ‘bazaar’ (I guess that’s the name now?) and do the updates.
Lots to consider… but for now, I’m doing the installer infrastructure first, setting up the DB and filling it with content, and making sure symlinking works as expected, then I’ll do the installer (the UI/UX) then I’ll look into porting existing data and how to manage user config (auto-update or not, downgrade if FVTT version changed, and things like that), then I’ll move to integrating it with the importer itself.