>a) fishtools adds a Info.Format tag to the metadata of all its CHK@ >files (even when it's only used from a map file) > >b) FIW and fcptools use that small metadata you mentioned above > >c) some other tools may use even other metadata or use none. > >d) if the file has been dropped from freenet, you cannot insert it as >you do not have it ;-) and if you have it, it has been inserted by you >and so you can use your upload software to reupload it. > >When it goes to mapfiles, it seems to me that you can use the mapfile to >determine the uploading client from it (from the order of the lines and >the position of the default file). > >However, it would be good to have some "best current practice" for >metadata attached to files...
definitive.. as long as there is "just a handfull" of insertion tools, there is still a chance to unite on a "common practice" or even create a definitive standard of which metadata to include in CHKs. >There are precisely two reasons. One is that it is a chunk in a >splitfile, the other is that it is a file that has been redirected to by >an SSK (possibly a manifest). These are two very similar cases. And >there are tools which will let you do this. The trivial solution to get >fproxy to do it would be to always create a redirect even if the file is >a CHK, just to not include the metadata. However I am absolutely not >going to do this, except maybe as an option. Because many sites DO >insert files as CHKs and then link to them as >/CHK@<blah>/<preferred filename> And I see no pressing reason to >implement such an option. one should separate between the currently cruising CHKs with - no metadata (data from SSKs or KSKs) - small metadata (FIW, fcptools) - more metadata (Fproxy) - unknown metadata (the ones to come or the ones we just don't know) and the future CHKs, as inserted as agreed on (please read on) i don't want to loose backward-compatibility on existing CHKs so older sites won't work anymore, but rather define a common CHK metadata definition for future CHKs >> d) if the file has been dropped from freenet, you cannot insert it as >> you do not have it ;-) and if you have it, it has been inserted by you >> and so you can use your upload software to reupload it. > >This ignores the case where you might want to "heal" someone else's >edition-based site, when the original author has vanished (or has >stopped reinserting it via empty transient nodes). > >Admittedly, that seems a somewhat unlikely case, but you never know. sure, like you never know which will arise in the future ---~~--- now my view on CHKs: CHKs are IMO pure "data holders". think of them as containers, which get a unique name on it because of the data which is held within. so if you drop a text into one container, the name should be CHK@TEXT (TEXT = hash of text) what you *do* with this text is not described, and it should not be described. if you want to view it as text/plain or as text/html is of no concern for the data itself! separate -content- and -view at the content- example situation: ... so you uploaded your text into CHK@TEXT and now you want to set up a "rule of how to view the plain data". just insert a KSK@text-as-html, which consists of a metadata area, which liks to CHK@TEXT and describes the mimetype of text/html if someone else has the same text or tries to reinsert your text, one must get a key collision, because the text *data* is already there if someone tries to insert a "view CHK@TEXT as text/plain", then one will get NO key collision on the VIEW, but on the DATA ending this scenary, you have three files: CHK@TEXT --- the raw data KSK@view-text-as-html --- link to CHK@TEXT, and a mimetype of text/html, describing what to do with the TEXT KSK@view-text-as-plain --- link to CHK@TEXT, and a mimetype of text/plain,describing what to do with the TEXT if you add the view to the data, like the currently available programs do, you end up with just two files: CHK@VIEW-TEXT-AS-HTML --- text and "view as html" CHK@VIEW-TEXT-AS-PLAIN --- text and "view as plain" smaller? i don't think so, because the data itself got doubled! so cleaning up the relations between content and view (the data and the metadata section) will - cleanse the metadata soup - define a standard of metadata in CHKs (which should be NO METADATA AT ALL - IT'S DATA, NOT A VIEW AT IT!!!!) - increase datastore capacity, because the data itself will collide more - create a more flexible view-handling on data - not allow questions to arise like "i have a mimetype specification in the map and one in the CHK, which one do i use?" - make future insertion tools or other stuff consistent in metadata handling thank you all for responding to my previous mail, i hope you will be equally engaged with this mail :) HAND _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
