On Fri, Oct 27, 2006 at 06:12:58PM +0100, toad wrote: > On Fri, Oct 27, 2006 at 07:04:31PM +0200, bbackde at googlemail.com wrote: > > On 10/27/06, toad <toad at amphibian.dyndns.org> wrote: > > > > > >Well, any external keys may not be "clean" CHKs. They might even be > > >files inside containers etc. Although not if they are big files. So if > > >you want to cleanly support externally originated keys you may need to > > >support multiple keys per SHA-256. > > > > Good to know. So I think I have to add this support for multiple keys. > > I hoped the encoding would be deterministic, but I accept if you say > > this is not the case (especially for big files). > > It is basically deterministic, as long as you specify the same MIME type > and filename. However there may be manifest lookups, container lookups, > (either way, using keys embedded originally in freesites), different > MIME types, and different filenames.
The following might be helpful, feedback would be useful: 1. Provide a "canonicalise" function via FCP. Either as a flag during a normal request, or as a separate function, it might be useful to be able to follow all the redirects until it ceases to be a simple URI (i.e. you reach a splitfile or similar structure). 2. For any file over some arbitrary size, don't include the top-level metadata in a container. 3. Allow selective inserts. It has long been planned to support reinsert-on-demand via: a) On a failed request, providing a list of the failed keys (or some unique identifier thereof) b) On an insert, allowing such a list to be included to indicate that we should only insert specific blocks. We can extend this concept further. We could tell the node to only insert the top 1 or 2 levels of a splitfile. We could even support a don't-insert list as well as a do-insert list, and include in the don't-insert list all blocks from another file with the same contents. (This is the long way around; we can macro this as an OverlapKey=<URI> option, which downloads the specified file, and includes all blocks therefrom). Something useful to develop an API for, IMHO, although not needed immediately. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20061027/077aef8b/attachment.pgp>
