19 lines
No EOL
1.6 KiB
Markdown
19 lines
No EOL
1.6 KiB
Markdown
# HTTPS-based protocol spec
|
|
|
|
When using HTTP, Venus will generate a warning and attempt to use HTTPS due to security issues.
|
|
|
|
## Conventions
|
|
|
|
All paths used are relative to the path provided by the user.
|
|
|
|
## Pulling
|
|
|
|
To start out communication, the client will attempt to access the file `.venus/VERSION`. It will then verify that it supports the specified protocol and version, before getting `.venus/default/BRANCH` and `.venus/default/MOD`. It will then get the specified branch file and retrieve each mod, populating it's own `.venus/MOD_ORDER`. It will then apply each mod's object(s) to it's own local copy of the repo. After this, it will get `.venus/branches/LIST` and loop through each branch, getting the branches, mods, and objects.
|
|
|
|
## Fetching
|
|
|
|
Similar to git, Venus supports fetching(the process by which mods are recieved but objects are not). In this scenario, all that is done is verifying that the server is still up with `.venus/VERSION` before getting the branch file, checking if the local branch is up-to-date, and if not, downloading the modules but not the objects.
|
|
|
|
## Pushing
|
|
|
|
Pushing is achieved by simply creating POST requests to the necessary files and using HTTP basic authentication with a user-provided username and password to change the files. To prevent race conditions, the server MUST lock modifications to a specific IP address plus username and password combination when the file `.venus/LOCK` is updated with any body, and unlocked after either a timeout of 5 seconds since the last request from this combination or the file `.venus/UNLOCK` is updated with any body. |