#413 new enhancement

mutable files: expose version info to HTTP clients? — at Version 6

Reported by: warner Owned by:
Priority: major Milestone: eventually
Component: code-frontend-web Version: 1.0.0
Keywords: mutable integrity versioning webapi wui Cc:
Launchpad Bug:

Description (last modified by zooko)

in #328, we overhauled the internal API for mutable files, to make them safe to use for structured data that requires test-and-set semantics. But this is not currently exposed to the webapi: clients using HTTP can only blindly overwrite mutable files, making them unsuitable for carrying more structured data that must be manipulated outside the tahoe node.

I'm not convinced that passing a servermap outside (and back into!) the tahoe node over HTTP is a good idea. Maybe passing a handle to one might be safe.

If you like this ticket, you might also like #906.

Change History (6)

comment:1 Changed at 2008-06-01T20:48:57Z by warner

  • Milestone changed from eventually to undecided

comment:2 Changed at 2008-12-06T05:04:45Z by warner

Zooko and chatted a bit about this tonight. It might be sufficient to pass a single version identifier. Mutable files have a sequence-number / roothash pair which points to a specific version of the file's contents. This does not contain as much information as the full servermap, but it might be enough.

The webapi for this might look like:

  • the t=json form of a directory listing could include "version=XYZ" as an extra element in the JSON
  • dirnode operations could accept a new argument which provides test-and-set semantics, perhaps "if-old-version-is=XYZ". The webapi protocol would only apply the requested changes if the "current best version" is also described as XYZ
  • the human-oriented "wui" could acquire if-old-version-is= arguments on all the buttons it provides. If the directory has been changed between the time the directory page was rendered and the time someone clicks a button, the operation would be rejected with a note encouraging the user to reload the page (and thus get the latest version).

Both mutable files and directories could have a control like this.

comment:3 Changed at 2011-07-23T02:20:12Z by davidsarah

I don't think that the sequence number alone is sufficient for test-and-set semantics, since there might be different shares with the same sequence number. By 'roothash', do you mean a hash that depends on the contents of the (encrypted and encoded) current version, or one that only depends on which file this is? If the former then a (sequence_number, roothash) pair would be sufficient.

#993 will probably add an internal API to get the sequence number. Should this get the (sequence_number, roothash) pair instead?

comment:4 Changed at 2011-07-23T02:21:24Z by davidsarah

  • Keywords integrity added
  • Milestone changed from undecided to eventually

comment:5 Changed at 2011-07-24T03:35:51Z by zooko

"roothash" means the root of the Merkle Tree over the (encrypted) shares of one specific version of the file, so it is sufficient to uniquely identify one version. Yes, everything that talks about "versions" of mutable files should specify the version as a (sequence_number, roothash) tuple.

comment:6 Changed at 2013-07-26T23:22:56Z by zooko

  • Description modified (diff)
Note: See TracTickets for help on using tickets.