added chunking/paging info to the spec
This commit is contained in:
parent
f752f9deeb
commit
bab155e698
1 changed files with 2 additions and 1 deletions
|
@ -11,6 +11,7 @@ This is the working structure of the 9p filesystem:
|
|||
* `/ctl`: Write-only control file for inputing system commands
|
||||
* `login PW`: Authenticate with `xrxs` -- password is hashed against realm password hash
|
||||
* `load CART`: Load a cartridge
|
||||
* `chunk TYPE N`: Load data of type TYPE and chunk number N
|
||||
* `create REALM`: Create a new realm (start a new game) -- must have a cartridge loaded
|
||||
* `protect REALM PW`: Protect the realm with a password if not already.
|
||||
* `enter REALM`: Join an existing realm
|
||||
|
@ -23,7 +24,7 @@ This is the working structure of the 9p filesystem:
|
|||
|
||||
* `/slot`: After loading the cartridge, its ROM is read from here; Read-only.
|
||||
|
||||
* `/data/`: Any supporting data that comes with the cartridge will be found here; to serve different files to different users, perhaps all resources of one filetype should be concatenated (ie, one file for all sprite data, one file for all text data, one file for all sound data) and let the client read whatever offset/length they need; read only
|
||||
* `/data/`: Any supporting data that comes with the cartridge will be found here; They are in three parts: `sprite`, `audio`, and `text`. Because `uxn` is limited to 64-128kb input files, the filesizes of these data blobs should be 64kb max, and the `chunk` command should be used to page different files into the service when needed. The files on the server should be like `TYPE_dataN` where `TYPE` is one of `sprite`, `audio`, and `text`, and `N` is a nonnegative integer. `data0` is the default loaded if no specific chunk has been requested. Inputting a command `chunk sprite 2` will make `sprite_data2` available under `data/sprite`, and so on.
|
||||
|
||||
* `/realms`: Open/saved realms, read-only. Realms and their associated universe are backed by real files on the server so that they can be preserved across service instantiations, in a directory structure like: `realms/<realm_name>/{realm, universe}`. Realms can either be solo, open, or protected; Open or protected realms can have limited member numbers. Depending on the cartridge, these settings can be user-managed or managed by the cartridge itself. Realms are listed per line upon reading the file like: `realmx 1 4 1`. `realmx` would be the name of the realm. The first number is number of members, second is member limit, third is 1 if protected, 0 if not. `0 1 1` represents a protected solo realm that is empty (saved game with password). `0 1 0` represents an unprotected solo realm that is empty (saved game with no password).
|
||||
|
||||
|
|
Loading…
Reference in a new issue