[tahoe-dev] How should extensions provide cap management user interfaces?
nejucomo at gmail.com
Sun Jun 1 20:19:27 UTC 2008
The purpose of this email is to explore the trade-offs in designing UI
schemes for managing caps.
The web interface does not explicitly provide any such mechanism,
which forces users and wapi clients to manage caps themselves (the
most obvious being browser bookmarks).
This explicit lack of convenience can be seen as an overall gain in
user experience, because (browser) users are forced to learn and
understand the nature of cap URIs.
However, if they use an extension which provides its own scheme for
tracking caps, the trade-off is made in the opposite direction.
So the question I'm interested in is: Should extensions:
a. Refuse to manage caps, forcing the user to do so?
b. Manage caps in whatever manner they chose, with no consistency?
c. Manage caps following some convention that most other extensions use?
Common schemes include browser bookmarks and the CLI root_dir.cap
convention. Recently the CLI introduced the alias system (see ).
Currently the fuse_a implementation mounts the tahoe directory found
in $BASEDIR/private/root_dir.cap onto the mountpoint specified on the
commandline. This was more of a shortcut than a design decision.
Ideally the interface should take a local directory mountpoint and a
Now, as an extension developer, should I support any of these
conventions: root_dir.cap, aliases, browser bookmarks?
I'm inclined to not support any convention and force the user to
specify the cap on the commandline. However, if there's already an
established alias mechanism, it seems a shame not to support it.
If the alias scheme becomes the status quo, how does that affect the
user interaction trade-offs? If it becomes status quo, would it make
sense to move it into the wapi layer? If not, why not, if all
extensions use that scheme already?
 I just added a ticket due to my confusion about the relationship
between root_dir.cap and aliases:
More information about the tahoe-dev