Well, it seems right now that CHKs, SVKs, KSKs and SSKs (whew ... did i get them all) are separate entities to the end user but I see that being rather cumbersome in the long run.
In my crystal ball I see the future freenet user hitting the button "Save to Freenet As ..." and then just entering a guessable text string with an optional description. In the background, the data is chopped up into little pieces with each chunk saved under a CHK. These pieces are listed in a SVK or as SSKs to provide and updatable layer. The final reference to the SVKor SSK is provided with a KSK to verbally share with friends. All the generated SVKs, SSKs, SSKs and KSK are stored in a bookmark file for future use/updating/purging. On subsequent/refresh request, the client can first check for the KSK. If that is missing, then it goes after the SVK/SSK. If that is missing then it goes after the individual CHKs. If there are not enough of those left then it gives up. If it finds any of the above in their entirety, then the keys above the last valid level are reestablished/reinserted. Mike > From: Ian Clarke <ian at octayne.com> > Subject: [Freenet-dev] An intuative user interface for 0.3 > > I think one thing we need to apply some brain-power to is how best to > present concepts such as SVKs, CHKs, redirects, subclasses, and > eventually searching, to the user, through a GUI interface, in an > intuative fashion. Should we treat keys as objects, where clicking on > them allows you to insert some data, request some data, or > (eventually) update the key? > > Some discussion around this would be most useful as people begin to > write GUI interfaces to the new SVK, CHK, etc mechanisms. > _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
