> >>>Actually, I just got another idea on how to handle them with a new key > >>>type. Let's call it a Time Redirection Key (TRK). The key is designed so > >>>that it will always route to the same part of the keyspace for a specific > >>>updatable file. When someone initially uploads a document, they point to > >>>this routing keyspace, and a request goes in that direction. This > >>>keytype has an unencrypted meta-value that is basically an estimate for > >>>the next update time. If a request reaches a node with a key that has a > >>>next-update-estimate time less than the current time, it continues on > >>>until the search finds a node with a next-update-estimate that is greater > >>>than the current time. If the request fails, it returns with the most > >>>recent value for the key found in the request chain.
this sounds no better than most of the ideas going around for editions right now. defeats the purpose of implenting updatable keys in the first place _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
