>From "Scott Young" <scottyoung at adelphia.net> >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 would make a request as long as a DNF only occur if the current time is >after estimate update time and the publisher hasn't updated the content. If >a publisher has new content by then, the nodes get the most recent version >with the same time cost as a DBR. If it isn't updated, well then it takes >longer, but you'd still get the last published version. > >any thoughts? > >-Scott Young >
Something similar to this was worked out in a bit more detail a little over 2 years ago: (at least, it looks similar to me) http://www.geocrawler.com/mail/msg.php3?msg_id=4421682&list=928 This was the result of some discussion you can look up, but nobody seemed to find any horrible flaws with it or anything, maybe it's time to move on to implementing it. -- Benjamin Coates _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
