start accepting "/cap/" instead of "/uri/" in the URLs #428

New Issue

zooko · 2008-05-30T03:48:22Z

zooko commented

2008-05-30 03:48:22 +00:00

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.

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.

zooko added the

labels 2008-05-30 03:48:22 +00:00

zooko added this to the 1.1.0 milestone 2008-05-30 03:48:22 +00:00

warner commented

2008-06-01 21:34:29 +00:00

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.

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.

warner commented

2008-06-03 21:35:06 +00:00

Done, in changeset:9f59ecafbbef6d83.

warner added the

fixed

label 2008-06-03 21:35:06 +00:00

warner closed this issue

2008-06-03 21:35:06 +00:00

Sign in to join this conversation.