Open ccoverstreet opened 2 years ago
The design decision to only allow one version of a JMOD could also simplify how JMODs are accessed. Right now, JMODs downloaded from Github could have a near infinite number of @commit
endings, which makes tedious to update the JMOD name on an external device. A proposed change to the JMOD format would be removing the @ suffix and storing the commit name inside of jablkoconfig.json somewhere. One way to do this might be to nest the actual module config within a Jablko specific config:
{
"jmods": {
"github.com/author/jmod": {
"commit": "abcdef",
"maybeOtherFields": "here",
"config": {
"stuff": "here"
}
}
}
}
This kind of design would allow for more control over JMOD behavior like limiting the number of threads a JMOD can use
Big whoopsie, with the new config format, there is a really weird recursive config effect that occurs when trying to update the JMOD config.
Right now, there is no quick way to update a JMOD. This process should be made as easy and simple as possible to encourage users to update. A decision on how to handle JMOD versions must be made in order to implement this feature. Personally, I see no reason to allow for multiple versions of the same JMOD to exist at the same time (when downloaded from GitHub). This greatly simplifies the upgrade process by keeping the same data directory and passing it to the new JMOD version. Since not all updates may progress smoothly, I may create a method for letting users pin a JMOD to a specific version or tag.
A sample upgrade process may look like this:
The default argument for update would be
latest
and would follow the above process. Alternate arguments would be the tag of the version the user wants to update to. On the admin panel, it may be better to just have users enter the JMOD name with a new version argument instead of having a button for each JMOD. That way, installing and updating JMODs is done by the same method.