> The difference between the popogation of this update, and the > propogation of an insert is that when an insert is propogated, > you can be sure that Freenet won't be full of nodes which are > caching the data which you are inserting.
That's really the central reality of the whole issue: old versions will be cached and distributed, so the simple Insert/Fetch method will fail. One or the other, or both, must be burdened with going a little further to ensure that the latest version inserted is more likely to be the one fetched. Discouraging or disallowing caching of SVKs won't work, because even though it's not a performance issue if they're just redirects to CHK document bodies, caching is used for deniability and robustness as well as performance. One question to consider: might it be acceptable from the user's point of view if he knew ahead of time that fetching the "latest" version of a document required more time than merely fetching a non-versioned one? I'm inclined to think so. Freenet is really optimized for CHKs, and that's where I see the majority of the data being put. SVKs are clearly needed, but if they're a little slower I think that's OK. It is, after all, something like a search: multiple things need to be found and compared. So I think adding a bit of probing-beyond-first-key-found to the fetch is acceptable. It might not be sufficient, so inserts may have to so a little probing-beyond-insert as well, and both should propogate revision knowledge they find along the whole route. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lcrocker.html> "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
