make the wui show the underlying LAFS model -- one WUI page per link in LAFS #277

New Issue

zooko · 2008-01-15T21:56:39Z

zooko commented

2008-01-15 21:56:39 +00:00

If you are looking at a directory and you want to get a read-only link to a child of it, currently you have to get the read-only URI and then prepend that with <http://127.0.0.1:8123/uri/>. It would be nice if there were a "read-only-link" hyperlink next to the "URI-link" hyperlink. But for that matter, maybe the time has come to make all representations of caps emitted by tahoe start with <http://127.0.0.1:8123/uri/>. Then we could simplify the wui to offer the hyperlink to the file and a read-only hyperlink (if and only if you have write access to the file). We could remove or move into a special metadata-page the JSON and text-plain links, and remove entirely the URI and readonly-URI links, the URI link for files, which is identical to the actual hyperlink to the file, and the text-plain link.

If we implement #103 -- "navigate by URIs in webish.py" -- then we can remove the URI link for files, too.

Therefore, we can have a nice simple wui with at most two hyperlinks per child: the read-write link (if appropriate) and the read-only link (if appropriate). In addition to those two links, there would be a set of actions (buttons) available, if appropriate: delete, overwrite, rename, check, view metadata.

If you are looking at a directory and you want to get a read-only link to a child of it, currently you have to get the read-only URI and then prepend that with `<http://127.0.0.1:8123/uri/>`. It would be nice if there were a "read-only-link" hyperlink next to the "URI-link" hyperlink. But for that matter, maybe the time has come to make all representations of caps emitted by tahoe start with `<http://127.0.0.1:8123/uri/>`. Then we could simplify the wui to offer the hyperlink to the file and a `read-only` hyperlink (if and only if you have write access to the file). We could remove or move into a special metadata-page the `JSON` and `text-plain` links, and remove entirely the `URI` and `readonly-URI` links, the `URI` link for files, which is identical to the actual hyperlink to the file, and the `text-plain` link. If we implement #103 -- "navigate by URIs in webish.py" -- then we can remove the `URI` link for files, too. Therefore, we can have a nice simple wui with at most two hyperlinks per child: the read-write link (if appropriate) and the read-only link (if appropriate). In addition to those two links, there would be a set of actions (buttons) available, if appropriate: delete, overwrite, rename, check, view metadata.

zooko added the

labels 2008-01-15 21:56:39 +00:00

zooko added this to the eventually milestone 2008-01-15 21:56:39 +00:00

zooko self-assigned this 2008-01-15 21:56:39 +00:00

zooko commented

2008-01-18 22:16:26 +00:00

Hm.. The more that I think about this, the more I realize that our wui is attempting to simplify something about the underlying model from the user, and that it might be better to make this underlying thing explicit in the wui.

This underlying fact is that files are standalone objects which have a contents and a size but not a name or any other metadata, and that the entries in directories are links to files, with metadata associated with the link but not with the file.

Make sense?

So for example, you can have two different directories that contain the same child, and it really is the same file -- for example if it is a mutable file (or a directory), and it gets change, then the change will appear in it regardless of which parent directory was used to get to it.

So a way that the wui could be refactored to follow the underlying model more closely would be for the web page representing a directory to contain buttons only for the actions that effect a link: delete (which should be renamed "unlink" in the wui), rename, follow (i.e. a hyperlink to the wui page child), and examine and change the metadata. Then there could be a per-file page which contains the operations that you can do to a file: view its contents (a hyperlink to the actual contents), view its contents read-only (a read-only hyperlink to the actual contents), view its size, check its health, and overwrite it.

But this would make the normal task of navigating from a directory listing to the file contents into a two-click operation instead of one-click. Also is would make all other operations on files, such as checking their status, into two-click operations. Relatedly, suppose that there is an HTML file which contains a hyperlink to another file which is stored in Tahoe, and you click that hyperlink. Currently, the wui will serve up the file contents to you (which is good), but it doesn't make available the controls that you can do to that file: check its health and overwrite it.

Currently there is no way to give someone access to a mutable file so that they will be able to change it without also giving them access to some parent directory which points to the file. They don't actually require access to any parent directory in order to change the contents of the file or to check its health, but the wui has no way to give them those controls other than by showing them a parent directory.

So perhaps the best wui would have a small bit of HTML which would be visible in a frame at the top of a file when the file is viewed directly, and then the directory page can have just links directly to files. :-)

Hm.. The more that I think about this, the more I realize that our wui is attempting to simplify something about the underlying model from the user, and that it might be better to make this underlying thing explicit in the wui. This underlying fact is that files are standalone objects which have a contents and a size but not a name or any other metadata, and that the entries in directories are links to files, with metadata associated with the link but not with the file. Make sense? So for example, you can have two different directories that contain the same child, and it really is the same file -- for example if it is a mutable file (or a directory), and it gets change, then the change will appear in it regardless of which parent directory was used to get to it. So a way that the wui could be refactored to follow the underlying model more closely would be for the web page representing a directory to contain buttons only for the actions that effect a link: delete (which should be renamed "unlink" in the wui), rename, follow (i.e. a hyperlink to the wui page child), and examine and change the metadata. Then there could be a per-*file* page which contains the operations that you can do to a file: view its contents (a hyperlink to the actual contents), view its contents read-only (a read-only hyperlink to the actual contents), view its size, check its health, and overwrite it. But this would make the normal task of navigating from a directory listing to the file contents into a two-click operation instead of one-click. Also is would make all other operations on files, such as checking their status, into two-click operations. Relatedly, suppose that there is an HTML file which contains a hyperlink to another file which is stored in Tahoe, and you click that hyperlink. Currently, the wui will serve up the file contents to you (which is good), but it doesn't make available the controls that you can do to that file: check its health and overwrite it. Currently there is no way to give someone access to a mutable file so that they will be able to change it without also giving them access to some parent directory which points to the file. They don't actually require access to any parent directory in order to change the contents of the file or to check its health, but the wui has no way to give them those controls other than by showing them a parent directory. So perhaps the best wui would have a small bit of HTML which would be visible in a frame at the top of a file when the file is viewed directly, and then the directory page can have just links directly to files. :-)

zooko changed title from ~~simplify the wui~~ to simplify the wui; make the wui show the underlying tahoe filesystem model

2008-01-18 22:16:26 +00:00

zooko commented

2008-01-18 22:40:49 +00:00

Oh, but this header frame must be absent on a normal HTTP GET -- HTTP GET is the way to get the actual data. So we need some nice RESTful way to indicate whether the wui/wapi server should just give me the data or give me a control panel for the file as well as the data itself in a separate frame.

Furthermore, if someone gives me a hyperlink which would yield just the data of the file, I want to be able to somehow easily navigate to the control panel for that file

I suspect that the RESTful (and the object-capability/WebKEYful) way to do this is for the control panel to be a separate resource from the file itself. I suppose <http://127.0.0.1:8123/view/$CAP> could return the page with both the control pane and the file contents pane, where <http://127.0.0.1:8123/data/$CAP> could return just the file contents.

Oh, but this header frame must be absent on a normal HTTP GET -- HTTP GET is the way to get the actual data. So we need some nice RESTful way to indicate whether the wui/wapi server should just give me the data or give me a control panel for the file as well as the data itself in a separate frame. Furthermore, if someone gives me a hyperlink which would yield just the data of the file, I want to be able to somehow easily navigate to the control panel for that file I suspect that the RESTful (and the object-capability/WebKEYful) way to do this is for the control panel to be a separate resource from the file itself. I suppose `<http://127.0.0.1:8123/view/$CAP>` could return the page with both the control pane and the file contents pane, where `<http://127.0.0.1:8123/data/$CAP>` could return just the file contents.

zooko commented

2008-05-10 19:03:30 +00:00

See also #418 (URI scheme), #221 (give proper filenames on download), #217 (DSA-based mutable files -- small URLs, fast file creation), #102 (smaller and prettier directory URIs), and #103 (navigate by URIs in webish.py)

warner commented

2008-12-06 04:57:15 +00:00

in the current code, this "control panel" is obtained by appending "?t=info" to the /uri/$CAP URL. The t=info page contains read-only links, storage index strings, any other data we can extract from the URI, and buttons to perform check/verify/repair. The t=info page for a directory also contains buttons to start deep-check/build-manifest/deep-stats operations.

The webapi has changed a bit since this ticket was first created. Mutable files can be accessed without going through a directory: /uri/URI:SSK:... allows GET and PUT, as well as POST with a variety of ?t= suffixes (for the benefit of HTML forms).

I wouldn't object to a parallel namespace for getting at this metadata/control-panel. Perhaps /info/$CAP ?

in the current code, this "control panel" is obtained by appending "?t=info" to the /uri/$CAP URL. The t=info page contains read-only links, storage index strings, any other data we can extract from the URI, and buttons to perform check/verify/repair. The t=info page for a directory also contains buttons to start deep-check/build-manifest/deep-stats operations. The webapi has changed a bit since this ticket was first created. Mutable files can be accessed without going through a directory: `/uri/URI:SSK:...` allows GET and PUT, as well as POST with a variety of ?t= suffixes (for the benefit of HTML forms). I wouldn't object to a parallel namespace for getting at this metadata/control-panel. Perhaps /info/$CAP ?

zooko changed title from ~~simplify the wui; make the wui show the underlying tahoe filesystem model~~ to make the wui show the underlying LAFS model -- one WUI page per link in LAFS

2012-08-27 18:39:41 +00:00

zooko commented

2013-05-09 03:25:41 +00:00

#1499 is related to this, possibly a special case of this.

Sign in to join this conversation.