Robert Bihlmeyer <[EMAIL PROTECTED]> writes: > Edgar Friendly <[EMAIL PROTECTED]> writes: > > > > But for the first alternative, accessing CHK@xyz directly will not > > > give you a proper MIME type, [...] > > > If this is the case, fproxy (or whatever client you're using) needs to > > be fixed. > > How is fproxy going to whip up the MIME type from thin air? > oops, I misread what you were saying. Yes, accessing the CHK directly won't get you the mime type, but if you know enough about the file to access the CHK directly, you should know the mime type.
> > > Do we really need to work around these insertion mistakes? In a way > > > it's /not/ the same data if it has a different MIME type. > > > But there's no reason to hold two copies of a large CHK if the only > > thing that differs is the MIME type. > > Did I say there was? But deprecating metadata on CHKs is not the only > solution to this common(?) mistake. I'd rather see insert clients give > users more guidance about the MIME type. > > -- > Robbe The best case for insertion is that any reasonably sized file gets inserted as a CHK so that there's the biggest chance of it colliding with an independent insert of the same data. If people put metadata in their CHKs, it severely decreases this possibility. Linking to CHKs from SSK cdocs also allows for pseudonymous "approval" of CHK contents, which is a good thing, given that a CHK could contain *anything*. Thelema -- E-mail: [EMAIL PROTECTED] Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
