Specific list for diffrent hubs

DarkFuneral · Post by **DarkFuneral** » 2004-01-18 11:32

I would like a feature that allows me to use diffrent filelists for diffrent hubs. In that way, hubowners are able to create spechubs for spectopics and will have better control of the files within the hub and they will be able to lower the minimum share for entering, without question the quality of the visitors.

Gratch06 · Post by **Gratch06** » 2004-01-18 11:44

From the rejected features tracker:

[ 657143 ] Specify shares based on hub

Todi · Post by **Todi** » 2004-01-18 11:44

This is a rejected feature, which means it will not be implemented in DC++.
The alternative is using one client for each hub you want a different share in.

jbyrd · Post by **jbyrd** » 2004-01-18 12:04

This is not a feature that I would find particularly beneficial, but I can definately see how it would be beneficial to others. I am well aware that it is in the rejected feature tracker, but that is because arne said it is too much work. But what if someone else were to write a patch, would it be rejected by arne (since he didn't have to do the work)? If so, then I move to remove it from the rejected feature tracker.

Todi · Post by **Todi** » 2004-01-18 12:23

Well, imho there are more good reasons for putting it in the rejected tracker. For one, it would mean users will most likely share as little as possible on each hub, i.e they will probably only share the kind of content the hub favors. Which will mean you will have to go into a lot of hubs to find certain content, even when it means getting it from the same user. And let's not forget that sharing is what DC is (supposed to be) about.

I can also imagine this taking more resources and bloating the client, since it will have to separate each hub's searches and has to keep track of which hub every user is in. Not to mention having one filelist for every hub, which will get confusing in the long run..

DarkFuneral · Post by **DarkFuneral** » 2004-01-18 12:48

Well.. the mainpoint of the idea is to create spechubs and it will become easier for people to find what they are looking for. Lets not think of the possible ways to "share as little as possible", because i think the most users share as much as they can in order to support the filesharingnetwork and principle. At least i want to beleave that.

I have 100-120 GB worth of TV-shows and would like a spechub for tel.shows without other crap.

Sedulus · Post by **Sedulus** » 2004-01-18 22:30

if you search the forums for this, you would see that there is a protocol limitation complicating matters

but yes.. there are some hubs that disallow pr0n, so different filelists per hub would be beneficial.

McDC · Post by **McDC** » 2004-01-20 04:56

The need for a better share manager is becoming more evident as hubs gets more specialist with particular rules. One of these rules being rar in certain reg. hubs.

Together with hub dependent sharelists you also need virtual folders so you can accommodate the specific rules and still have a nice clean looking share.

As to rejected features the author sometimes acts against better judgement. The rejected download/uploadlimiter feature demonstrates perfectly what will happen and it was precisely what I had been predicted. The author failed to understand how you would compensate for such a feature and now its to late. The proper way to deal with a limiter was to make the settings visible and let the hubs to sort them out. Now theres netlimiter and no control.

Todi · Post by **Todi** » 2004-01-21 18:27

Small update.

It seems there is actually a client (or atleast, there will hopefully be in the close future) that supports different shares on different hubs.

Tasman wrote:(cut)... I've got one feature I'm sure he doesn't though...thats different shares in the same client for favorite hubs (it's true....SDCC 0.04 whenever I manage to find the time to work on it and then release it will have this feature...). The layout has a single flaw; you must share all folders you want to share in favorite hubs by default (ie a hub not in your favorites which you connect to). So as long as you just add hubs to the favorite hub list and specify which folders to share it should be ok...(cut)

The client in question is Shadows DC Client (SDCC).

jbyrd · Post by **jbyrd** » 2004-01-21 18:49

Good deal.

BTW, I understand your argument, Todi. I don't particularly like the idea, but I didn't think arne's reason was very reasonable. Just knit-picking.

ehrichweiss · Post by **ehrichweiss** » 2004-02-26 17:40

Todi wrote:Well, imho there are more good reasons for putting it in the rejected tracker. For one, it would mean users will most likely share as little as possible on each hub, i.e they will probably only share the kind of content the hub favors. Which will mean you will have to go into a lot of hubs to find certain content, even when it means getting it from the same user. And let's not forget that sharing is what DC is (supposed to be) about.

Your arguement doesn't hold that much water. If a user is only a member of one hub anyway, they'll tend to share "as little as possible" anyway. And the reasons to have such a feature are much more varied and valid.

Besides the pr0n arguement that has been brought up, I run a hub especially for sharing magic and magicians are VERY unlikely to want to share magic files with non-magicians and as a matter of fact, that is THE reason I searched for such a thing because users on my hub don't want to share with laymen.

Now, how about implementing something like what filetopia(yuck) has where certain parts of your share can be password protected...or granted access to on a per-user basis. That wouldn't be too difficult to implement but it would mean the whole file list would be available so there'd still be the issue of getting banned because you were "sharing" pr0n files even if the operator couldn't download them.

BTW, it would be a simple matter to see if someone was on another hub that you are on to grant them access to your alternate file list.

P.S. Running a second instance of the client doesn't work unless you like being put into passive mode. The first client to run gets priority on the tcp connection and that's the end of any chance of getting an active connection on the second client.

Todi · Post by **Todi** » 2004-02-27 07:50

ehrichweiss, this thread takes up some of the problems with this concept, it's not as easy as it sounds.

joakim_tosteberg · Post by **joakim_tosteberg** » 2004-02-27 10:23

ehrichweiss wrote: P.S. Running a second instance of the client doesn't work unless you like being put into passive mode. The first client to run gets priority on the tcp connection and that's the end of any chance of getting an active connection on the second client.

What? I've been running up to three clients in active mode on the same time without any problem, just be sure to use different ports for them.

Specific list for diffrent hubs

Specific list for diffrent hubs

Share Manager