Multiple Share list settings

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Locked
GenRabbit
Posts: 1
Joined: 2004-07-15 01:05

Multiple Share list settings

Post by GenRabbit » 2005-01-26 10:23

What I would like to see is the possibility to set up different share list for different Hubs.
Some hubs only allows, rars, some only anime, some only porn.. and so on and so on.

This is irritating at times so I wondered How this could be implemented??

I was thinking on this, and they way I see it easiest done is. First build up one Default share. Just like it is today.
Then as user decide to build a new share any added file/folder added to this new "sharelist" will get its info from the Default sharelist. If its not added there, you cant add It to the new share list either. When the files are updated in the default Sharelist, the other share list get automatically updated with the info from the Default Share list. When a new favorite hub is added to favorites, a pulldown menu could be added where alternative file list appear. If none is choosen, Default is used.

A second wish is a window where all files that is detected in more than one location is displayed. (like the queue windows).

Thanks

ullner
Forum Moderator
Posts: 333
Joined: 2004-09-10 11:00
Contact:

Post by ullner » 2005-01-26 11:01

This has been requested many times before. I suggest you use the search button.

BSOD2600
Forum Moderator
Posts: 503
Joined: 2003-01-27 18:47
Location: USA
Contact:

Post by BSOD2600 » 2005-01-26 11:33


GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Re: Multiple Share list settings

Post by GargoyleMT » 2005-01-26 12:06

GenRabbit wrote:This is irritating at times so I wondered How this could be implemented?

See, that's the rub. It cannot be implemented easily - the crux of it is that you cannot easily identify connections with the hub they came from easily. You could keep a lot state about the pending connections, and that may work relatively accurately. It's pretty easy to concoct situations where that breaks down and becomes completely inaccurate.

GenRabbit wrote:A second wish is a window where all files that is detected in more than one location is displayed. (like the queue windows).

The information on duplicates is already stored in the system.log file, if you have it enabled, just type /log system in chat to load it in a text editor.

PseudonympH
Forum Moderator
Posts: 366
Joined: 2004-03-06 02:46

Post by PseudonympH » 2005-01-26 22:21

Does the problem remain even with the ADC connection tokens? I thought that was one of the problems they were intended to fix.

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2005-01-27 00:56

The problem do not occur with ADC. You cqan safely identify which hub a user has connected from using the magic cookie. Atleast if the connection was initiated through a hub. ADC is so general. ;))
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2005-01-27 12:30

ivulfusbar wrote:At least if the connection was initiated through a hub.

If people connect directly with no communication through the hubs, any NMDC solution would also break. ADC has flexibility to move in this direction with searches, so it may eventually do the same with connection attempts.

Locked