From 0573a3426d1f44e5ce1b73e07bc3acd2140d9b6b Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Wed, 26 Sep 2012 18:20:07 +0000 Subject: [PATCH] Cf. URNs -- what about extendings keys to URNs? The there's no guarantee that will get the identified content in always the same format. --- ...er_network_data_stores___40__gnunet__44___freenet__41__.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn b/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn index 33928b6bd4..0e3d8ac0ae 100644 --- a/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn +++ b/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn @@ -22,4 +22,4 @@ For example: * Similarly, a backend for the hashes used in **BitTorrent** and **magnet links** could be used. If we want a trackerless mode, then probably it's a similar case for a "global"/built-in special remote that needs no local setup in each repo. Using a selected tracker would mean setting up a special remote in our repo. * **Git** itself can be viwed as place to look for the content. There could be a corresponding backend and a builtin special remote (needing no extra setup) to look for the content among the objects stored in the local Git repo. (What if we have a copy of a file that we've put under the control of git-annex in a previous Git commit? We could get it from the object store of Git.) * **Venti**, [[**Tahoe-LAFS**|todo/tahoe lfs for reals]] would need a backend for their hashes, and a specially setup special remote in each repo where we'd like to use them--because these are not "global" system, we must setup the path to the instance of the filesystem we'd like to use. -* probably, there must be other interesting cases of this kind.... (I'm also thinking about using somethng like a bibliogrphic information as a key, but then it wouldn't guarantee identical files: the same paper can be stored in diffrent formats, etc.) +* probably, there must be other interesting cases of this kind.... (I'm also thinking about using somethng like a bibliogrphic information as a key, but then it wouldn't guarantee identical files: the same paper can be stored in different formats, etc. Cf. , via .)