> 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.
This is what I was saying about requesting an item when their are multiple items per "key"/name. You can request something and if it's spam, outdated, or in some other way not what you're looking for, you can do a probing-beyond-first-key-found request that includes criteria for selecting the best key. It will have the exact same behaviour as this method of updating, but instead of only checking the insertion timestamp, it will check against any number of user-specified criteria which are in the public metadata. It should be possible to also specify criteria to filter results with so that you can, for instance, specify that you don't want to file with the given CHK. It's just a generalized version of the update-on-request update method that works for criteria other than insertion timestamp. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
