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: > >On Fri, Oct 27, 2006 at 06:23:09PM +0200, bbackde at googlemail.com wrote: > >> On 10/27/06, toad <toad at amphibian.dyndns.org> wrote: > >> > > >> >So Frost already assigns each file a unique identifier, being its > >> >SHA-256? Interesting. The purpose being presumably to support multiple > >> >filenames and MIME types for the same file? I mean, exactly why is it > >> >beneficial to index them by SHA-256 rather than by key? > >> > >> - independency from node and maybe changing CHK keys *g* > >> - take load from node by computing SHA inside Frost JVM > >> - SHA computation does not need an expensive encode > >> - SHA is verifyable with external tools > > > >:) > > > >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. > > FYI: the SHA is used to uniquely identify a file for insert-on-demand. > Someone offers a file, and if a request for this SHA-256 arrives the > upload begins (maybe, some factors are considered to not to create an > insert cascade). > This way I don't have to put load on the node (encoding, key > generation) until the file is actually requested. So you'll have a definitive CHK for each file, which is the CHK you get by inserting it as CHK@ with no filename and no MIME type. Then you have a list of auxiliary ones which *might* work. > > > >It doesn't at the moment, but desktops often detect by contents, and may > >save MIME types (as well as thumbnails) in extended attributes or a > >database in the near future. > > > >Having a proper MIME type allows freenet's filtering to work. This is > >especially nice with HTML downloads. You can queue on the global queue a > >particularly stubborn freesite, and when it's eventually downloaded (in > >future it will tell you via an event on the homepage or via an RSS feed > >or something), you can click on it on the queue page and safely view it. > >Same with images, audio, video if you have enough temp space (although we > >don't filter audio/video at present). > > OK. If I add support for multiple CHK keys then I could set the mime > type too. If it ever changes and the key changes this would not hurt > then... > > >> >> For me the download of binaries > >> >> from freenet is the same as FTP, emule, bittorrent, ... you get a > >> >> octet stream and thats it. No need for mime types here. For html, yes. > >> >> Needed because intented to be shown in browser directly... > >> > > >> >I'm not convinced of the need for such a sharp dividing line. > >> > >> Its no need, but thats the current situation... > > > >Well, Freenet already straddles the border between filesharing and web > >browsing, I suppose that's my point. > > Lets start a new era :) That's the idea. :) > > Thanks for the constructive discussion.... Cool. Good luck with Frost; I look forward to file sharing actually working on it. (Although I've always been resolutely pro-global-queue). > > I hope other readers of the list think this too... -------------- 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/0e6c4169/attachment.pgp>
