Scott Young <scottyoung at adelphia.net> writes: The scheme definitely sounds interesting. Here are some points to ponder, though:
> Multiple keys can be tried at once. Once the first document is hit, > it is downloaded then displayed in the browser. If all keys are requested simultanously, this will result in version "0" being the most popular. Chances are big that it will trickle in first, so users will always see the /oldest/ version on their first try. We'd at least have to advocate users that they may have to retry a few times if they see very old editions. The second issue is whether it is good for the network if it has to keep 15+ old versions of every site. If the requests are on the other hand staggered or even serialised it is much more likely that the system won't need to request (IOW keep alive) these old versions. It's slower this way, of course, but you also have better chances to get the newest version. You mention that the system can scale from seconds to years. I'd rather give publishers a choice what the smallest time unit should be (not unlike the DBR frequency parameter). This makes for less dynamic and therefore less unnecessary requests. Most people will probably choose a day, which saves 16 bits (=requests) when compared to seconds. Maybe you already propose something like this with the following: > This can be optimized by accurate "guessing" at how deep the first > part of the tree is (like if a site updates daily then do the tree > depth closest to a day) and if it finds something there, it starts > proceeding down the tree. It's not entire clear how guessing would work. Remember that the problem case is when *nothing* is known about a site locally. Once we already have a not-so-old version available, there are only a few bits to try. I say leave it to the authors to (over)estimate their own update frequency. > I am willing to work on this after I figure out the internals of Freenet > (although the poor documentation is slowing me down). You could have an external program do the correct inserting and requesting for now. That should be sufficient to see whether the scheme works in practice. -- Robbe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.ng Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20011205/86935022/attachment.pgp>
