 |
Web Hosting by Netfirms | Free Domain Names by Netfirms |
|
|
|
|
|
|
BearShare Pages BearShare Wish List| Interface | Wish | Description | Status* |
|---|---|---|---|
| IMPORTANCE: 6 back to top | back to navigation |
|||
| Uploads | Separate Queue for Smaller Files | Sometimes, one's queue is almost filled to the brim with 100 MB files that take a while to upload. But there's that dinky 26KB upload at the bottom of the queue. It seems pretty unfair to the downloader that he has a 26KB file and he is queued 20/20. There should be a queue for smaller files (say less than 5 MB, but it should be able to be changed by the user) so that the user with the 26 KB file could get his download done really fast. However, this queue should be about a quarter of the normal queue i.e. if there are 16 normal queue slots, there should be 4 queue slots for smaller uploads. Also, the smaller queue would have to have hard coded bandwidth limits imposed so as to not disrupt the upload speed for normal files. The bandwidth limit should be from 20-35% of the total uploads bandwidth. This setting could be controlled by BearShare and be adjusted when the normal queue is not very full. If the small queue is full, but the normal queue still has slots, then the smaller files that could not get a slot in the smaller queue will get sent to the normal queue to wait in line. Once slots open up in the smaller queue (shouldn't take long), then the first small file in the normal queue will get sent to the smaller queue. If the normal queue is empty, then the smaller files can just use that queue, but if the smaller files are occupying more than a quarter of the queue slots when a big download comes, the first quarter will be shunted to the smaller queue, while the remaining smaller files will stay in the normal queue. |
No |
| Misc | Tiger Tree Hashes | Instead of a hash for a whole file, a hash for each chunk of the file. This feature is useless by itself, but it is needed for two features. | Plan |
| Downloads | Corruption Prevention (THEX) | With Tiger Tree hashes, BearShare can compare each chunk of the file with the hash it is supposed to have. If a chunk was corrupted, BearShare would just redownload that chunk. This is essential for byte-identical files to work (such as .zip, .iso, etc.). If you were to download a 700 MB ISO and one byte was corrupted, you would probably be pretty mad (unless you have an OC- line). Now imagine if BearShare would chop up that 700 MB file into seven-hundred 1 MB files, each with its own hash. If a chunk were to be corrupted during transfer, BearShare would notice that the hash of the downloaded chunk is diffferent to the hash of the chunk on the remote computer and redownload that chunk and continue with the rest. The remote BearShare could send a packet at the beginning of the transfer with the Tiger Tree hashes for each of the 700 chunks. Every time the local BearShare downloads a chunk, it hashes it with Tiger Tree and compares it to the hash in the packet that was sent from the remote computer. I know some of you will claim that TCP/IP is theoretically fail-safe. Then you know that all it takes is one stupid NAT between you and the source computer to screw up the download. There are a lot of cheap NATs out there which slap a new CRC on the packet without validating it first. Now imagine a corrupted packet arrives at one of these stupid NATs. The NAT will slap a new CRC onto it (flagging it valid) and passes it through. TCP/IP won't be able to see that the data is corrupted and passes it onto the recieving application (BearShare, in this case). The result, your file is corrupted. The only way to prevent this is to do an additional hash check in the application itself. |
Plan |
| Uploads | Partial File Sharing | Partial File Sharing would greatly increase the sources and chances of getting a large file. Most sources for these large files are often few-in-between and overloaded. | Plan |
| Misc | Instant Messaging | There are many against and for instant messaging; myself slightly leaning toward the pro side. Instant Messaging would be a great tool for downloading and uploading. Say someone is downloading something from you that can be downloaded faster from the program web site (I have done this a few times on KaZaA Lite). You can just send them a message telling them it would be faster. Another use would be, when you are downloading, to ask the uploader if the file is the full version, if it is good quality (if a Bitzi ticket is not available). Also, there should be an option to block a user or all users from instant messaging you. [Editor's Note: This wish has been promoted to Importance of 6. Since the future of chat capabilities in BearShare is unknown, we need something to replace the current decentralized 'BearChat.'] | No |
| IMPORTANCE: 5 back to top | back to navigation |
|||
| Blocking | Periodic rescanning of 'hostiles.txt' | BearShare only scans hostiles.txt upon startup. Someones there is this aggressive servent trying to get your files, but not as aggressive to warrant an automatic block. BearShare should rescan hostiles.txt every five minutes or so, or, if possible, rescan it only when it detects a change in the file. | No |
| Blocking | Uploads Blocking | There should be an option to block an uploader, just like in the Downloads page. The blocking should be temporary; when BearShare exits, the block is forgotten. | No |
| Chat | Resolve Chat User Names to IP Addresses | Sometimes (or a lot of times) you will see someone uploading form you that has the Version of 'BearShare 4.2.0b21' or something like that. Since you are on a 'szUserAgent = "BearShare 4.2"' server, chances are that that uploader is on the Chat server. There should be a way to get a person's IP Address without having to (a) Browse Host the person (b) Download something from them or (c) ask them to download a file from you. A few places to put the User's IP Address: (a) in a new column in the Users Pane, (b) in the User's info, or (c) following the user's name (i.e. <linuxrocks: 127.0.0.1>) |
Test |
| Connections | Automatic Port Forwarding | A lot of people are using routers these days. All they have to do to be able to recieve incoming traffic is enable port forwarding. Sadly, a lot of novice users don't know how to make this simple change. Is BearShare were to use UPnP (Universal Plug 'n' Play), BearShare could automatically communicate with the router and enable port forwarding. Now, Vinnie, before you say 'no', implementing UPnP is not that difficult anymore. The needed APIs are present in Windows 2000, Me, and XP (making the feature Windows 2000, Me, and XP, however). Read this: http://msdn.microsoft.com/library/e...asp?frame=true. I admit that although a lot of people use routers, there still is a big portion without UPnP. But in the future, the number of UPnP-enabled routers is going up, not down Besides, implementing UPnP is needed for the next feature I want to suggest: | No |
| Connections | Random Port Choosing | More and more ISPs are blocking port 6346. Still, BearShare can't get around it by itself. All the user has to do is change the default port, but again, you bump into the 'novice user' problem. But what if BearShare were to choose a random port every time it starts? The ISPs won't be able to get a grip on the Gnutella network anymore (well, at least not on the BearShare Island™). More importantly, BearShare can detect is a port is blocked or in use by switching to another port and trying again until it can find a port where it can connect, even if that means a firewalled port. However, there's a reason I want this idea bundled with UPnP: If BearShare were to switch ports on a user's home network, it would automatically become firewalled because that home user has not set up port forwarding in his router for the new random port. But what if BearShare were to 'inform' the router with UPnP of its new port and enable port forwarding? BearShare wouldn't be firewalled anymore even though it is randomly switcing ports at each restart. All of these aren't really needed 'basic survival' features, but they would automate a lot of problemms that novice users encounter and don't understand.
|
No |
| IMPORTANCE: 4 back to top | back to navigation |
|||
| MAGNET | MAGNETs to files already shared should Error | When one downloads a file through the use of MAGNET URIs, the download is automatically added to the Downloads list (if the user has specified that action). However, if a file is already shared, there is no error message; just a message in the normally hidden Console. There should be an error message if the file is already shared. | No |
| Chat | Ability to change User Name without disconnecting from Chat Server | Sometimes you want to change your nickname during chat. The only way now is to change the User Name in the Chat Options window, disconnect from chat, and then reconnect again. There should be an option such as '/nick <newnick>' that will allow the user to change his nickname during chat without disconnecting and reconnecting. | No |
| Chat | Ability to Change Servers | Now, the only way to chat on a different server is to drop the current chat server and then connect to the second one (if there are only two chat-capable ultrapeers). There should be an option such as '/server <IP>' that would allow the user to disconnect from Chat, and then connect to Chat on the specified server. | No |
| Chat | Paste Text with Line Breaks | BearShare should either allow line breaks in Chat and just display them as a box (undisplayable character), or it should allow you to paste text with line breaks in an other box and just cut off the text after the first line break. | No |
| Misc | More Metadata | BearShare should be able to read the metadata from files, including ID3 tags for MP3's. | No |
| Search | Searching by Metadata | BearShare should be able to search by metadata, not just by looking at the filename. This way, improperly named files (with correct metadata tags) can be found more easily. | No |
| GWebCache | GWebCache Reporting/Advertisement | BearShare should be able to advertise a GWebCache to other GWebCaches, like Gnucleus and Shareaza. This would be a good tool for Webmasters who use BearShare; they would not have to get a different servent to advertise their GWebCache. | No |
| GWebCache | Manual GWebCache Connections | We should be able to type in a GWebCache into the Hosts connect box and connect to it. | No |
| Search | Filter for Results | Options to show/hide search results. Possible filters include: all the current search options, files already shared, firewalled sources, client type, bitrate, time, files with only one source, files already in download list, etc. | No |
| Library | Search for Files in Library | An option to search for files in the Library. | No |
| Library | Drag and Drop in Library | An easy way to move files between folders. | No |
| Downloads | Manually add sources to a Download | We need a way to manually add sources to a download without editing the .dat file. Say you find a source for this file that has 114 MB / 121 MB on a different computer. You can just write that source down on a piece of paper and when you get back to your "first" computer, you can tell BearShare to look query that source for that download. | No |
| Misc | Integrated Partial AVI Previewer | BearShare's Theater lacks the ability to preview incomplete AVI movies. There should be an integrated program that can rebuild the index of the AVI file, such as DivFix or AVIPreview. | No |
| Search | More information for Browse Host | If a Browse Host (or possibly a Search) is in progress, but no results have been returned, there should be a message in the Results pane, such as, "No results have been found yet." If a Browse Host ends and there are still no results, replace this message with one of the following: "Browse Host complete, no files shared." "Browse Host failed, Browse Host not enabled by the host." "Browse Host failed, the host does not support Browse Host." "Browse Host failed, the host and the client are firewalled." "Browse Host failed, BearShare could not connect to the host." (Generic error) |
No |
| Uploads | Specific Progress Bars | If an upload starts requests a chunk at 50% of the file (in the middle) then the progress bar should not show as half full. That is a lie. The progress bar should have a little segment STARTING at 50% and extending to the end of the chunk (say 54%). If an upload requests 2 non-consecutive chunks, then there should be 2 separate shaded areas on the progress bar. | No |
| Downloads | Delayed 'Find More Sources' | Should work the same as in searches, have BearShare send find more source requests every 6 seconds. Currently, BearShare sends all of these requests at once. | No |
| Library | Option for New Files to be Unshared by Default | Either a setting for all new files or a folder by folder basis. | No |
| Search | Browse Host in Uploads | Two things:
|
No |
| Misc | DNS Resolution via Self Lookups | It was a very cool feature to see the location and country flag for clients. However, this required hostnames, and that required looking up every IP that passed by. This was too stressfull for the user's computer, as well as the DNS servers. However, what if clients provided their own hostnames to the server? If each client looked up it's own hostname, and then told others when establishing connections (hosts, downloads, and uploads), then it wouldn't be so stressfull for the user's computer, and it wouldn't be so stressfull for the DNS severs. The client's hostname would be somehow provided though HTTP headers of conections. Even if you don't bring back the flags and the locations columns in BearShare, you could use these provided hostnames for statistics, like WebStats (or the proposed BearShare visual statistics). |
No |
| Misc | Option to change name of all files from MAGNET links | Currently you set the name for files that have no name from the magnet link, the option should be there to change the name given in that comand prompt. | No |
| IMPORTANCE: 3 back to top | back to navigation |
|||
| Downloads | Active hosts at the top of a swarmed download | When you are downloading a file with a page or more of sources, it is kind of annoying and tedious to check which hosts ARE 'Active' or 'Transfer'ing. BearShare should put the sources that are transferring at the top, and the Active sources below the transferring sources. | No |
| MAGNET | MAGNET URIs to Browse a Host | This could be an entirely new tag, or a request for '/' on the remote computer using existing syntax. [Editor's Note: This wish has been demoted from an Importance of 5 from an Importance of 4. It is not that important.] | No |
| Downloads | Automated 'Find More Sources' | During unattended downloads, one cannot get the best sources for the file when the computer is left unattended. BearShare will just keep on using the hosts it found either through Searching or Download Mesh (hopefully this will eliminate the need for this point). BearShare should automatically 'Find More Sources' for a file about every 15 minutes, but never less than ten. If multiple files are downloading at one time, BearShare 'Find More Sources' for each file every 2.5 minutes, because if BearShare initiated a 'Find More Sources' for all of the downloads at the same time, then the Gnutella network and the user's computer will be overwhelmed with Searches and Search Results.Note: If Download Mesh proves to be worthwhile, then this feature is not needed. | No |
| Search | Advanced Searches | BearShare should implement Boolean search parameters (+, -, etc.), not just filters. | No |
| MAGNET | MAGNET URIs that support multiple files | According to the MAGNET URI specifications, MAGNET URIs can have multiple files (or parameters) 'attached' to them. BearShare should be able to handle these types of magnet links (by downloading or searching for all the files on the link). | No |
| Downloads | Bandwidth averages on downloads | Sorting by actual bandwidth is fruitless | No |
| Uploads | File Broadcasting | Were Partial File Sharing somehow coupled with broadcasting so 1 uploader simultaneously sends a large file segment to multiple people at once without having to increase bandwidth by 100% for every user after the first, then files which once took weeks to propigate across Gnutella might start doing so in hours! I doubt this is possible at all though. | No |
| Search | Remote Directories for Browse Host | Shareaza and Gnucleus currently support showing the remote directory tree when browsing a remote host. This feature is very useful at times, but it also can get in the way. Make showing directories optional but possible (check box in Search pane). | No |
| Search | Button to clear Queued 'Find More Sources'/Searches | If you select a large number of files and click find more sources currently BearShare sends a search by hash at 10 per minute. Other searches are added on the end of this queue. Either give standard searches priority so they are sent before the find more sources or have an option to cancel all pending searches. | No |
| Uploads | Ability to toggled Shared Status for individual files | Sometimes you just notice that someone is downloading a file from you that is not supposed to be shared. It would be easier to toggle the shared status of a file directly from the Uploads page. The 'Shared' context menu item in the Library's Files pane could be added to the Uploads' context menu. | No |
| IMPORTANCE: 2 back to top | back to navigation |
|||
| Connections | Automatic connect to an Ultrapeer | Sometimes, one always connects to the same Ultrapeer every session i.e. Tom's server when beta testing. It would be a good feature to have BearShare automatically connect to an ultrapeer. If that's not feasible, then there should be an autocomplete feature added to the Manual Host Connect box in the Hosts page. | No |
| Hosts | 'Browse Host' context menu item | Sometimes you see that ultrapeer sharing 15000/180GB and ask to yourself, "What the heck is that person sharing???" You would have to use the File -> Browse Host command and enter his IP Address. To speed up this process, there should be a 'Browse Host' option in the Hosts context menu. It shouldn't be too hard to add. | No |
| Chat | Automatic connect to Chat | Once a connection to a Chat-Capable Ultrapeer has been established, BearShare should automatically connect to the Chat. This will make things easier for us. (Not that important, but still useful) | No |
| Misc | 10 second Bandwidth averages | 10 second averages would provide smoother sorting. | No |
| Search | Time Stamp Results | With timestamps, old results can be filtered out or automatically removed. This would make keeping search results across launches more useful. | No |
| Chat | Export Session | An option to save all text from a chat session to a text file. | No |
| Misc | Report & Phrase Query Hit Info for More File Types | This is yet another Shareaza feature. BearShare should report information on Applications, Movies, Office Documents, HTML Pages, etc. in search results. And even MP3 files don't report the actual metadata (Artist, Album, and Title ID3 tags are not sent with search results). About the phrasing part... Shareaza clients are sending this info to us already. Let's make BearShare smart enough to show this info in searches, even if it cannot send the info itself. (See More Metadata and Searching by metadata.) | No |
| Misc | Consistent Sorting Algorithm | Bearshare uses different ways to sort, sometimes it sorts from small to large when the triangle points up, sometimes it sorts large to small. This needs to be standardized, this way it looks very amateuristic. Oficially when the triangle points DOWN the results should be ordered with the LARGEST items ON TOP of the list. This applies for lists in all BearShare, from search to downloads, uploads, and so on. | No |
|
|
|