On Wednesday 10 June 2009 13:33:44 xor wrote: > On Tuesday 09 June 2009 16:29:37 Matthew Toseland wrote: > > On Tuesday 09 June 2009 12:51:09 xor wrote: > > > On Wednesday 03 June 2009 23:47:49 Matthew Toseland wrote: > > > > Bug 3040 suggests getting rid of the Key column and linking to the key > > > > from the filename column. We link to the key from the identifier column > > > > already but it isn't shown in simple mode. I am not sure I agree with > > > > p0s's logic: > > > > > > > > The purpose of the filename column is to show *where the file is being > > > > downloaded to*. Downloads to temporary space don't have one, although > > > > they are unusual. Sometimes the filename will be a full, absolute path, > > > > usually it will be downloads/blah. > > > > > > > > So out of filename, identifier, and key, which do we keep in simple > > > > mode? IMHO it makes more sense to keep the key than the identifier. We > > > > can make the key slightly more user friendly by decoding spaces and > > > > foreign characters in the visible version, and we already truncate the > > > > crypto stuff. > > > > > > The problem is not only that the Key column is redundant, it is also that > > > it *does not fit on 1280x1024 for medium length filenames (freEbooks with > > > Author - Date - Title for example)* which is already a rather high > > > resolution. > > > > I really hope aforesaid books are legally redistributible ... We have a > > policy of not providing tech support to known pirates ... > > I said "FREEbooks". Such as www.gutenberg.org > > > > > > I would suggest to instead of removing it rename the key column to > > > "Download link" and have the CONTENT of the column be always a link to > > > the key named "Link" instead of a text which relates to the actual fie. > > > For multiple reasons: > > > > > > 0. "Download link" is easier to understand than "Key". > > > > > > 1. It does not matter what the link looks like in plain text, the user > > > just wants to copy-paste it usually, so you do not need to show it in the > > > column. > > > > > > 2. Showing an abbreviated link is confusing, the user might copy the name > > > of the link instead of its destination. > > > > > > 3. When showing an abbreviated link, we will always abbreviate it to only > > > display the key type and the file name. But the filename is already > > > displayed in the file name column so its redundant! > > > > Unless it is a download to temporary space, in which case we have NO useful > > information about which file it is that is being downloaded! We could > > perhaps include the > > > > We could change "Key" to "Download link", but "key" is pretty universal, > > e.g. what should we say on the bulk downloads form or the fetch a freesite > > form? > > How about "Freenet address" instead of "Key"? I think thats a good compromise. > And please change the content of the column from "c...@.../filename" to > "Link".
That is exactly what we are arguing about. Let me spell it out again:
Freenet supports queueing downloads to temporary space. This can only happen
via FCP at the moment, but it is nonetheless a concern.
In simple mode, we do not display the Identifier.
For a file downloaded to temporary space we would not display the filename
either as it has none.
So what does that leave us?
Also, "Download link" ... we already have a download link, the "Download"
column. Which exists because there is a distinction between fetching the data
which has been downloaded via /downloads/<key> and fetching the data all over
again via /<key>.
IMHO the best solution is:
- Get rid of the Download link on downloads to disk. Keep it on downloads to
temp space.
- Change the Filename column to just show the directory we are downloading it
into, rename it to "Downloaded to", and link it to the local filename.
- Keep the Key column.
- Get rid of the Persistence column, and maybe replace it with an icon
indicating that a download is not persistent forever (anyone want to make
one?), which would be after the key and have a tooltip explaining.
- Put a type column back in, with human-readable versions of MIME types ("Audio
file" etc).
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
