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 > >
