[Tech] CHK keys with filenames

[toad]

On Wed, Nov 01, 2006 at 07:50:01PM +0100, freenetwork at web.de wrote:
> >> >Any other options?
> >>=20
> >> CHK at blah,blah,blah#filename.ext
> >>=20
> >> just like href-anchors
> 
> >How do href-anchors have anything to do with this? They simply refer to
> >a section within a URI; they aren't, for example, passed to the web
> >server, in the case of Fproxy. So using them would make Frost
> >incompatible with Fproxy, which is something to be avoided ideally.
> 
> Uhm.. maybe I should confront you with my thinkings about how this whole thing is planned to work.
> 
> I know '/' is a manifest lookup, therefore a CHK at blah/filename.ext would result in a manifest lookup in CHK at blah for filename.ext, as it would be with SSKs.
> If I understood your previous mails correctly you want to add a new metadata fieldset to the CHK metadata. This new fieldset contains the "original" filename (real: the filename the inserter thinks is suitable for this piece of data)

It's an idea that's been suggested, I'm not sure that it's necessary, or
that it fits in well with the current system.
> 
> Scenario 1 (inserter's filename specified, no external filename specified):
> So if I would request CHK at blah
> - FRED would search for CHK at blah
> - the data comes in
> - extract the fieldset and get the inserter's filename "by_inserter.txt"
> -- FProxy would return the data to the browser with the filename "by_inserter.txt" in the HTTP response
> -- Frost would be able to access the metadata field and save the data with the inserter's filename "by_inserter.txt"
> 
> Scenario 2 (inserter's filename not specified, external filename specified):
> For this scenario please assume '#' as being the divisor between the "pure" CHK-URI (CHK at blah) and the filename (filename.ext).

Not possible because everything after # is interpreted only by the web
browser.

> - FRED would search for CHK at blah#by_uri.txt
> - the data comes in
> - there's no fieldset present, therefore the data is passed along without a filename
> -- FProxy would return the data with the provided filename "by_uri.txt"
> -- Frost would extract the provided filename just like FProxy did and save the file as "by_uri.txt"
> 
> Scenario 3 (no inserter's filename specified, no external filename specified):
> - FRED would search for CHK at blah
> - the data comes in
> - no fieldset
> -- FProxy doesn't have a clue how to name the file and returns "download_123456.bin"
> -- Frost has no name either and either knows how to handle the retrieved data (r.g. internal commands, messages, etc) or uses a generated filename, too
> 
> Scenario 4 (inserter's filename specified, external filename specified):
> - FRED would search for CHK at blah#by_uri.txt
> - the data comes in
> - an fieldset is present, extract the inserter's filename
> -- now which filename to return to the client? the inserter's filename? the URI-provided filename? Prompt the user both and ask him? Or override one of the two?

The user-specified filename takes precedence, by definition.
> 
> I chose '#' as a separator because it does not comflict with a manifest lookup by '/' and is somewhat recognized already. '?' and '&' are used for HTTP/FProxy and are therefore useless. Thes would also have to be parsed by Frost and other clients which is bad, when 
> provided as '?filename=bla.txt" or even worse "?force=123&filename=bla.txt&mime=blafasel"

It is not difficult to parse ?x=y&z=a params, and ignore those which are
not relevant. And we can pass them into Fred over FCP with a little more
work, so the client doesn't need to worry about it.
> 
> >> easy to detect, easy to use, compatible with '/' for later functionality
> 
> >Later functionality?
> 
> keep the door open for something like this:
> 
> CHK at my_chk_site/some_nameless_file#filename_to_use.txt
> 
> which combines a manifest lookup '/' and an externally provided filename "filename_to_use.txt".

Of course.
> 
> >One possible way out of your concern would be to include both the
> >filename and the empty string in the manifest when inserting a CHK. But
> >this means that the two forms are not directly comparable, for a start.
> 
> no ugly kludges please... :)

Agreed!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/tech/attachments/20061101/1ae83693/attachment.pgp