> No single strategy for either the update or subsequent fetch will > work by itself; one must specify both sides of the operation and how > they will work together. Oskar and I believe that a deep-probing > fetch along with a simpler update will work. You propose a more > thorough update, but a simpler fetch (you don't really specify the > fetch, but I assume you intend something simpler). If your method > will really work, it would be more optimal for fetches and less for > inserts, which is a good thing. We should probably try both.
In that case I think we are largely in agreement, the point I was trying to make in my last email was that we had each provided one piece of a (hopefully!) two piece jigsaw. We were both correct to say that the other's suggestion was insufficient - but in combination they might do the job. > I think you mean Expiry (the term "timeout" is already a bit overloaded). > That's really orthogonal to this--any document can have an expiry time, > and some updatable documents might not want one. Certainly adding this > information makes the system perform better, but _relying_ on that is a > big mistake. I agree, it will be a trade-off for authors, providing a timeout would work well for, say, something that is regularly updated (like a Freenet version of /. for example!), but not so well where an author wishes to retain the possibilty of an update, without committing to update within any time-frame. The latter must accept that an update of this type of data (we could call this passive-updatable data as opposed to active-updatable data with the expiry time) would be less efficient and require longer to take-effect. Additionally, it would be good if Expiry's could be accurately timed, this would require that nodes standardize their time measurements according to GMT (or another fixed time). This requires a little more effort during configuration for node operators (unless Java can do this - I can't remember). > We also need to make clear that if these SVKs are redirects > to CHK full documents, expiry of the two is independent. Expiry on the > SVK means that it no longer point to an "up-to-date" document, though > some still may want to retrieve older versions by CHK. CHK documents > should never expire, really, just fall into disuse. Surely a SVK should just die when it expires, unless we want a non-up-to-date document to be returned in the event that an up-to-date version cannot be found? This might be troublesome, I think we should just delete expired (ie. non-updated) SVKs outright. > Perhaps some combination of the two might be best--your slightly > expanded update, plus a slightly expanded fetch (say, a fetch that > begins sending the data found, then makes 1 or 2 extra hops to > tell the neighboring nodes it has done so, allowing them to send > update messages if they happen to have a newer version. Sounds good to me. Ian. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
