>> >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) 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). - 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? 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" >> 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". >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... :)
