Open hackergrrl opened 8 years ago
If list is supposed to be easy to parse, I would left out the colon and just make first line a columns decryption (like ps
).
I take the usage of 'UX' here as specifically to refer to having 'least surprise', which is also the case with the files API for local operations. For the files api, it is unclear whether it should grow to have feature parity with coreutils, or just to support POSIX file operations. Implementing the POSIX interface in the context of distributed fs is tough and will take lots of research (plenty incompatible standards to sift through). While the issue with implementing coreutils-like local operations is that there are also plenty standards to sift through (among darwin, any bsd, linux, ...).
What is concerning of ipfs mount
, imo, is the perf. A well-thought ux won't substitute for this. Otherwise it could have been used to mount /nix/store
or to be used as git-annex
's backend by now.
To this date, there is no performant bittorrent fs to base on. Should this (ipfs mount ux/perf) really be the current focus of ipfs devs? Shouldn't optimizing for content-delivery use case be the first to be nailed? (i.e. refine the 'git' and 'torrent' part of ipfs first, then later unixfs)
From git-blame
stat of fuse/**/*.go
: cc @cryptix, @tv42
@Kubuxu: Agreed. If we really wanted to be consistent with mount
we'd do something like tmpfs on /tmp type tmpfs (rw)
per line, but this seems pretty unpleasant to parse using traditional methods.
@rht: Yes, UX roughly equates to the principle of least surprise here. I've updated the root comment.
@noffle i really like this. +1.
Additions:
ipfs mount
alias to ipfs mount -a
, and ipfs mount ls
be the listing.ipfs mount
to list, IF we add a compatibility message at the end, like: $ ipfs mount
/ipfs /tmp/ipfs
/ipfs/Qmfoobarquux /home/stephen/my-website
/ipns /ipns
# The mount command has changed, it now lists tracked mountpoints.
# For the original behavior -- mounting the mountpoints -- use: ipfs mount -a
One unrelated-to-this-UX-but-worth-considering-now thing is:
Good points @jbenet, thanks for the input. I've updated the top issue. I'd also be okay if we did the ipfs mount
-> ipfs mount -a
alias with a deprecation warning.
ipfs mount
is great, but it could be a lot more powerful and also borrow a lot of well established UX from the unixmount
command. (known as the principle of least surprise)mounting
Arbitrary IPFS and IPNS paths can mounted to the local file system. A user should be able to mount all of /ipfs somewhere, and then also mount /ipfs/Qmfoobarquux elsewhere.
ipfs mount /ipfs/Qmfoobarquux /home/stephen/my-website
ipfs mount /ipfs
ipfs mount /ipfs /tmp/ipfs
ipfs mount /ipns
ipfs mount -r /ipns
listing mountpoints
Here and throughout, output should be textual, line based, and trivial for external tooling to parse.
mounting all
It should be possible to configure mountpoints somewhere -- probably in
.ipfs
. Maybe in.ipfs/fstab
.additional
cc @jbenet @whyrusleeping @diasdavid @lgierth @rht