https://bugs.freenetproject.org/view.php?id=838 https://bugs.freenetproject.org/view.php?id=839 https://bugs.freenetproject.org/view.php?id=840
On Fri, Oct 27, 2006 at 08:01:43PM +0200, bbackde at googlemail.com wrote: > FULL ACK for all 3 points!!! I would love this! > Together with this the node could provide more detailed block status > during download to be able to show a progress bar like fuqid on 0.5, > or emule, that shows what blocks of the file were successful. > > Also the selective insert would help alot if you want to heal a file. > Currently it takes ages because each block is inserted again. > > Its not needed immediately, but please keep this in mind. I look > forward to a discussion about the interface. > > I am busy next days to implement multiple CHK keys per unique file, > and I look forward to provide an official beta release of the new > Frost soon... > > On 10/27/06, toad <toad at amphibian.dyndns.org> wrote: > >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. > > > > > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.4.5 (GNU/Linux) > > > >iD8DBQFFQkKIA9rUluQ9pFARAqk3AJ9Pf1KmNpdszTMoyt6qNWhMdp9IBACgnhXF > >AiYg7fe+MZkJ2cg29pWSgCQ= > >=RPoL > >-----END PGP SIGNATURE----- > > > > > >_______________________________________________ > >Tech mailing list > >Tech at freenetproject.org > >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > -------------- 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/20061028/02fefd5b/attachment.pgp>
