There *are* solutions to this. Standard solutions. Which are already implemented by every web browser. The filename on disk does not have to be, and often cannot be, exactly the same as the filename in the URI. That doesn't mean that we should be able to mutilate URIs at will. The ability to do so just increases the freenet learning curve. This is unnecessary complexity.
On Fri, Oct 27, 2006 at 08:58:29AM +0200, bbackde at googlemail.com wrote: > Let me add a sample scenario: > > A unix user uploads a file with the (valid on unix) name > "my*great*file.txt". > Each FCP application running on windows have to take care to not to > use this filename because it's invalid on windows. The application > have to use another filename for the request and for the real > targetfile on disk. > Without the mandatory filename the application could just auto-replace > "*" by some valid character and work only with the new filename as > targetfile. > > Constructed scenario, there could be solutions for this, but I think > you see the point... > > ---------- Forwarded message ---------- > From: bbackde at googlemail.com <bbackde at googlemail.com> > Date: Oct 27, 2006 8:37 AM > Subject: CHK with filename > To: tech at freenetproject.org > > > I heard that you want to make "CHK with filename" mandatory. What does > this mean ... > > I have to insert a file with URI=CHK@ and TargetFilename=abc. Then I > must request this file with URI=CHK at bla/abc? the CHK key itself is not > enough? > > The same file, but with different names, get another CHK key? > > What is the sense of this? You said it would be easier to find the > file in store, but why is this easier, the CHK is already unique? The > filename just adds another abstraction layer and you have to deal with > files of same name, but different content. Because of this you would > always have to use key+filename for lookups, why is'nt the key itself > enough for this? > > IMHO this concept leads to problems. I know that same files with > different names only have another key because the manifest is > different, the (hidden) datablocks itself have the same key. But how > should applications for file sharing and insert-on-demand work with > this concept? We share the file with a unique SHA identifier. If 2 > users have the same file, but with different names, this works well. > Now if there are the same files, but with different CHK keys because > the filename is different, the application would have to maintain a > list of all known CHK keys for a file with same SHA checksum, and it > would have to try to download one key after the other until a download > is successful. > > As you see, this concept adds more complexity to FCP2, with a > questionable benefit. Simple applications that count on this concept > would have problems later if there are alot of files from many users > floating around... they should respect that only the CHK key is the > URI for a file. This worked great on 0.5, everyone understand this and > its easier for all... > > Please don't make this mandatory. > > rgds, bback. > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > -------------- 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/20061027/f242a759/attachment.pgp>
