Opened at 2008-05-30T03:48:22Z
Closed at 2008-06-03T21:35:06Z
#428 closed enhancement (fixed)
start accepting "/cap/" instead of "/uri/" in the URLs
| Reported by: | zooko | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 1.1.0 |
| Component: | code-frontend | Version: | 1.0.0 |
| Keywords: | Cc: | ||
| Launchpad Bug: |
Description
This task might be nice to have in place for Tahoe 1.1.0, because then later releases that we put out, after Tahoe 1.1.0 is used everywhere and Tahoe 1.0.0 is not used anymore, can create URLs of the new form:
http://allmydata.org/pipermail/tahoe-dev/2008-May/000601.html
On the other hand, it may not matter, because the next release of Tahoe might (optionally) produce completely new URLs (a la #217 (DSA-based mutable files -- small URLs, fast file creation) and #102 (smaller and prettier directory URIs)), which are unusable to Tahoe v1.1.0 anyway.
Change History (2)
comment:1 Changed at 2008-06-01T21:34:29Z by warner
comment:2 Changed at 2008-06-03T21:35:06Z by warner
- Resolution set to fixed
- Status changed from new to closed
Done, in 9f59ecafbbef6d83.
Note: See
TracTickets for help on using
tickets.
I'm not opposed to this, but have we thought about it enough to be happy with "/cap/", as opposed to some other short prefix ("c", "u", nothing)?
I'd like to sit down and draw up a plan for "cap reification": what are the exact strings used to represent our various file/directory capabilities. We know that there will be at least two kinds (human-readable and packed machine-readable), and that we might want the human-readable ones to be browser-friendly (or 72-column friendly, or concise, or some combination thereof). And we've drawn up a couple of proposals based upon adequate crypto key sizes and "base62" encoding schemes, but we haven't finished the roadmap yet.
I don't think we need to finish that before making the cheap bet that http://NODE/cap/CAP is going to be useful. I've created ticket #432 for this purpose.