> > Oskar's update solution is nice in that it delays the update from the > > propogation of update notification. > > Nice except that there are two good reasons why it simply won't work, as > outlined in my previous email which you have conveniently ignored! > > I don't mind alternative ideas, but it is irritating when people > continue to advocate those ideas after I have pointed out the flaws, > and without addressing the points I make.
I had to go back and look up this thread because it was mistitled, but I don't buy your argument at all. Contrary to your assertion, Oskar did in fact address your points directly, and convincingly. If others didn't respond, maybe it was because we know that Oskar has more experience and a reputation for being right. I'm not entirely convinced that the idea will work well (even though it is largely the same as the idea I came up with independently), but I am convinced that your argument against it is specious. You assert that his probing-request update mechanism makes the assumption of a central location for the data. That's not true-- the data can be inserted from anywhere as usual, and stored at any node as usual. All he suggests is changing the request from "do a directed hunt for the first matching document in this part of the network" to "do a directed hunt for the latest matching document on this (slightly larger) part of the network". We are not proposing a mechanism that guarantees the latest version--but neither are you. That's just the Freenet way of things; not a guarantee, just a likelihood of success. My proposal is a little more reliable in that it begins the request with a specified minimum revision, but it otherwise similar. Secondly, you assert that this will interfere with the existing caching mechanism. This is so far from the truth I can't imagine how you can say it with a straight face. It doesn't change any existing behavior at all for any other key type, and the extension for updatable documents is so minor (especially compared to alternatives) that it doesn't seem likely to have any major impact. I also agree with Oskar that updatable documents ought to be small to further minimize any possible impact of these extended fetches and inserts; making them all empty redirects to CHK documents is a great way to do that, so we can even dispense with message bodies entirely if we want to. -- 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
