Handling paths as nicknames
The new API treats nicknames as paths. Even /renter/upload/foo.txt
will create a file called /foo.txt
, with a leading slash. What is the right way to handle these strings?
There are three areas that need attention:
- The API. I see no problems here (for now), but we might consider dropping the leading slash from nicknames.
- The renter. Currently the renter tries to save .sia files using their nickname as the filename, so with the new API it will be creating files with slashes in their names, which is a disaster. We probably want to perform some kind of escaping here. Alternatively, the .sia filenames don't really need to match their nicknames; they could be numbers (like the host) or something else entirely.
- The UI+siac. Things are pretty clean for the UI, since path handling happens behind the scenes, but in siac the nicknames are more in-your-face. For example, you'll need to include the leading slash with some operations, but not others (namely
rename
, since it takes a path as a URL parameter). We could play fast and loose here (tacking on leading slashes behind the scenes), or we could be strict and require an explicit leading slash in all calls.
A more radical alternative would be to ban /
in nicknames altogether. This is basically taking the position that siad should not know anything about paths, and that only the UI should be responsible for manipulating/parsing paths, using some other special character in place of /
. I can sympathize with this position, but I feel it will become increasing untenable as the software matures.
I plan to implement this stuff myself, but I'm looking for input as to what seems like a good design.