March 14th, 2005
|
| |
- Ultrapeers should drop search results with -4 or worse rating on Bitzi, as determined by file hash.
- There should be a way to rate files from right inside Limewire, right next to Block Host.
- More general Bitzi integration?
- Block host should (perhaps optionally) block every known source for a file, not just a random one of them.
- Small files with only one source are harder to get than they probably should be. Shortest-job-first queueing might be nice. Also, files that can fit in a single network packet should be sent in lieu of busy signals or other just-as-big responses that just mean the file will be re-requested shortly.
- It should be possible to save off a chunk of your pending-downloads list. It might be nice to have separate lists for results from separate searches, and to also have separate download directories for separate searches. Currently the only way to have that effect is to make multiple installs, one for each query, and switch among them. Nasty workaround, and a huge waste of disk space.
- Distributed hashing?
- BitTorrent capability? Large files you shared would automatically create and share a .torrent as well; compatible clients (i.e. with both gnutella and bittorrent capability) would display the two search results as one item and try to get the file from bittorrent.
- Caching of small files on ultrapeers?
- Cascading of small file downloads -- many jpegs on the same host tarred, sent as one transfer, and untarred transparently at the other end? Downside -- interrupted transfer might not be easily resumed, since only the exact same host is likely to have all of the same files.
- Performance is (still) poor on 1.5GHz CPU, 1GB RAM, cable inet system.
- What is with files of only 10-20K getting 3% done and then aborting spontaneously? Are there clients out there that can be put in a "leech without seeming to leech" mode in which they share thousands of files but cap uploads at 0.01kb/s and randomly drop connections? If so can these be punished somehow?
- 4.8.1 exhibits frequent hangs. The UI won't redraw and there is 100% cpu use. Even if its priority is lowered and there's a lot of physical RAM free, other apps are slow and unresponsive. Left alone it eventually recovers, only to hang again some time later. 4.6 did not do this, but it did have some sluggishness issues all the same.
- Duplicate file database. Every file that was downloaded successfully has its SHA1 added. Files with the same SHA1 are filtered from future search results. Downside: if you download a file and find it's been substituted with garbage (an ad, typically) you won't be able to try to get it again and hope to get the real McCoy. The file, when completely downloaded, must be rehashed and that hash put in the duplicate file database, so the original is still going to show up until you get it. This way you can also tell if the file has a misleading name or if the file should have been something else but a bad node substituted junk when you downloaded it.
- Integrated previewer. Newly downloaded files are moved to a "New files" list for review. You preview them and can delete, move to library, etc. Turned off by default; advanced users can turn it on. When turned off, files are moved automatically, i.e. the current behavior.
- Library organizer. Library tab should make it easy to create subfolders and move/rename files, to categorize stuff.
- Any time a search turns up a file that is in your library, the search query is remembered in a database associated with that file, and Limewire will return that file as a hit for any search for that query done by someone else. When you first download the file, and it is moved to the library, the search query that led to your downloading the file is associated with it in this way, and others get added later on. (These same duplicate hits get weeded out of your search results.) Thus if your search for "trees" produced an opaquely-named file like "DSC00156.jpg" it will be returned by your machine as a hit for "trees". If you later search for "plants" and this same file (same SHA1) is a hit, you won't see the search result, but that file will now match both "trees" and "plants" when your node is searched.
- More efficient sharing of a large library. Limewire gets slow and cranky with thousands of files shared, so how about having it share only one shared folder at a time, but change which one every so often; or making this an option. (A shared folder with only subdirectories won't count; one with files and subdirectories would have the files shared; the subdirectories would get rotated to eventually.)
- Ultrapeers should not drop search results unless they are actually overloaded, no matter how many hits for one query there are. (How widely supported is OOB result returning now, anyway? There's really no need for results to be limited at all, or for them to go through the ultrapeers; they should be sent straight to the querying node, save if they must go through one intermediate host to get past firewalls, just like a download.)
- Ultrapeers with dialup leaves should cache the smaller files on those leaves, and return (OOB) the cached copy of such a file as a hit where possible. This will take some of the burden off modem users, and make some of the files they host more consistently available. When a query matches a small (<500K) file on a modem leaf as determined by an ultrapeer, and that ultrapeer has cache space available, it should download the file itself, and pass on the file as it receives it to the requesting node. Subsequent requests for the file that reach that ultrapeer can return the cached file without the dialup host being bothered at all. The file expires eventually when not requested for more than some period of time.
 |