Proposal for QuickMod conflict prevention

proposal.md

Why?

It seems like there'll be several providers of QuickMod files, and especially with opensource mods like Buildcraft etc. it'll probably not be uncommon for a mod to exist at several different providers. Say we already have the buildcraft from curse, and now we install mod X from mc-get that requires the buildcraft from mc-get. Currently, as they have the same UID, the one from curse will be overwritten, which is not wanted.

Some terminology

• Repository (repo): provider of QuickMod files

Possible actions

Prefix all UIDs with a repo specific ID

Pros: Simple

Cons: We end up with multiple of the same mod in the mod browser it general user confusion

Ask the user when a QuickMod file is about to be overwritten

Pros: Also somewhat simple

Cons: From the example in the beginning; what if mod X requires a version of Buildcraft that only is available on mc-get, but the user still wants to keep the curse buildcraft?

Add repository info in the QuickMod file, and add a repository dialog

This would add/change the following fields:

• uid: An identifier of the mod, has to be the same for all repos.
• repo: An identifier for the repository of the mod
• verifyUrl: Stays the same, but the expected format of the reply is changed: <SHA512 of the QuickMod file>:<User-visible verify url>

The mod browser dialog would contain a list of tabs, with the value of repo as the title. The version select dialog would merge all version lists, and if a version is in multiple places the user would be asked.

There COULD also LATER be a dialog for selecting default repositories for usage in the version select dialog.

Pros: Non of the above cons, integrates with verification

Cons: A bit more involved

In the third idea, why not just toss out the uid field and combine the repo and mod fields to generate the uid?

Just realized I wrote down several thoughts at once there, editing it...

Also, there's no guarantee that the uid will be the same for all repos, but it doesn't seem like a big issue.

I considered adding a alternativeTo field that would be like uid, but more general (translocators instead of codechicken.translocators etc.), but I don't think it'll be needed.

That's the kind of thing we can always add later.