> Ok, the problem here is that if you have numerous documents all with the > same key then you can't use Freenet's routing mechanism to find all > version, in fact, you can never be sure you have found the latest > version. Further, how can you specify what version you are looking > for? The node which attempts to answer your request probably won't have > all of the versions to start with.
I've covered this a few times. All we need is to add filtering to Request. Add a field to Request that contains a list of CHKs. The node will ignore any key matches if matched file has the same CHK was one in the list. That way it will be _exactly_ like sending a normal request, smart routing and all, but it simply won't see the files that it isn't supposed to see. The way it would be used is that the user would request a file. If it was bad, they would request it against with the CHK of the bad file in the filter list. And then again and again until they got a good file. The client would have to be modified so that this process takes one button click per attempt. This could be used for sort of thing where their are multiple files stored under the same key and you only want one, such as sorting through spam. This approach can be extended to include public metadata. For instance, if you think the version number of a file is benign enough to attach to the file in a publically viewable way, then the Request can filter based on that. If the insert date was public, then looking for a new version would just mean putting the insert data in the filter list (although this might get older copies, too, and then you'd have to add their insert dates to the filter list, unless we made a more complicated <> filtering, which I think would be great). > The way I would approach this gives the same functionality, but doesn't > require such an upheaval in the way things operate. Each new version of > a document would be stored under a key like "documentname/0.2", and then > the key "documentname" would redirect to the latest version (this > obviously required that we have implemented data modification and > redirection - both of which are on the radar). This is a pretty nice way of doing things, assuming we get working updatable data. My solution isn't just for newer versions, but for combatting spam, too. And it keeps the exact same routing as current requests. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
