Michael Wiktowy <spam at mindless.com> wrote: > the general request (aka search): > > Someone is interested in a general subject (say mp3s) and maybe even a > specific topic (say a particular music group). They make an attempt at > guessing a key. This may just be a keyword. Since they don't know exactly > what they are looking for they certainly don't have a CHK so they send > off a data request without one. This request in smartly routed using the > KHK. > > At the node, the node sees that there is not a CHK included so it knows > that it is not looking for a specific file. So it takes the supplied KHK > and hashes it with the CHKs from its store one at a time and checks for a > match. Each time it finds a match it will take the metadata header from > the data in question and compile a list of metadata of data that has a > matching plain key. In the list it will include the CHKs of that data as > well so that the user can specificly request that data after viewing the > metadata.
Indexing under KHK:CHK is a good thought. A big problem we've been having previously is how to eliminate bogus KHK->CHK pointers where the CHK data doesn't have anything to do with the nominal KHK. Here, the pointers ARE the data -- constructed dynamically from the data in your store. If no one retrieves a particular KHK:CHK, the data dies and automatically takes down the "pointer" with it. Some kind of unrequest or whatever is still required to deprecate the data if you were somehow tricked into retrieving it, but at least you don't have to deprecate the pointers as well. One difficulty: how can you index data under multiple KHK names, without inserting it multiple times? theo _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
