>start quote< 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. >end quote<
Ok, it's probably just me, being fairly new and all. This TRK points to a CHK (of our content) and it contains an estimated update time. When they upload, they send a copy of the TRK with an updated estimate time (for the next revision) and it points to the updated content. Now, when someone searchs, they see if it's newer than the estimated update from the old TRK. If it is, they grab that version, and blammo, it's updated? Am I completely off track? It seems to be like a DBR (yes I know I said it already, and I was wrong before) except if there's not new content it automatically forks over old content? So people replace the TRKs in their datastore with new copies of TRKs? And if it's like I seem to think it is, doesn't that mean we have to upload content under a different filename each time? I think I'm waaay off. ::Alabaster wanders off to read Freenet theory papers again:: Alabaster -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021128/e719cbe5/attachment.html>
