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: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20061101/1ae83693/attachment.pgp>
