Ok, no more AOL. Sorry bout that. This might also be off the thread because it's not a reply to an actual email.
I went and sat on my bed and thought for a while. Here's what I came up with: ------------------------------------------------------------------------------ Goals of a Time Updatable Key a. Allow the author of a piece of content to update as in/frequently as s/he desires. b. Propagate new contet quickly c. Allow old content to available for reference d. Impose low network overhead e. Replace old content as the default f. No redirects (well, not really) TUK Structure/Internals/Blah a. Metadata 1. GMT Time of original insert b. Content Request to get TUK 1. TUK at myRandomPublicKey/somedir/index.html Result: Node looks for newest version of TUK 2. With ?time=...... Result: Node looks for newest version at time or before Request to store TUK 1. Add TUK to datastore unless datastore has exact match Brings Up.... 1. A node stores more than TUK with the same name 2. A node's TUKs from the same content/person/blah have dfferent timestamps and content 3. When a TUK is requested, all matching TUKs are compared to get newest/requested version. 4. If old content is not requested it will drop out of datastore normally 5. If old content is requested it qill be available but not by default 6. Not sure how to lower network overhead/storage problems 7. Content propagates quickly if popular. The idea is to serve the masses not the minority. 8. Large content will eat up datastore unless old content is not accesssed - Possible network attack - Except if attack's content is unpopular, attack fails Just my ten cents. Alabaster _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
