Possibility to create multiple filelists

[kazi]

Hi all,

Is it possible.. or would it be possible..  to create an option  to use multiple filelists? so that you can setup a filelist for every hub?  

Hope someone can do or knows..

thanks in davance

Kazi

[Skrollster]

First this doens't belong on a hubsoft dev forum but in a client dev forum..

and i guess that it is possible but i wouldn't recomend any one trying to get a dc++ mod to work with diffrent fillists...

the way dc++ now is built it is almost impossible to make it happen.. but i guess that a good programmer with tons of hours to spare could make it....

[bastya_elvtars]

It was DC:PRO, Sir.

And with using ADC protocol in the future, tis will become an everyday thing.

[Pothead]

I've seen this done in a version of oDC.  Problem with multishares, is if the person requesting a file list is in a hub where you have one share, and they are also in a hub where you have another share, then they don't always get the list they should.

[plop]

startup 2 clients, which both enter seperate hub's with the same nick but different shares.
now ask a buddy 2 join both hub's with 1 client, you can see that his client gets confused.
he might try 2 get the file from the wrong client.
i think ppk has also tryed 2 add this feature but like bastya said this isn't possible on the dc protocoll.

plop

[Pothead]

Using a work around, a share / no share option is possible.

[Pothead]

Originally posted by plop
startup 2 clients, which both enter seperate hub's with the same nick but different shares.
now ask a buddy 2 join both hub's with 1 client, you can see that his client gets confused.
he might try 2 get the file from the wrong client.
i think ppk has also tryed 2 add this feature but like bastya said this isn't possible on the dc protocoll.
plop

I've been thinking about this protocol issue, and the more i think about it, it seems more like a bug in DC++.  
Please correct me if i am wrong:
DC++ doesn't remember what Hub connection requests come from and which to send it too (it just passes a user, then sends to the first place it sees that user).

This is true as far as i can tell, meaning it's a DC++ bug, and not a Protocol issue.  If it passed HUB as well as USER this problem would disappear.

[GargoyleMT]

Originally posted by Pothead
Please correct me if i am wrong:
DC++ doesn't remember what Hub connection requests come from and which to send it too (it just passes a user, then sends to the first place it sees that user).

One of the cases is uploading to two passive users - by them issuing a $RCTM to you.  If they have identical nicks, and the timing is right, you'll have two incoming connections offering the same nick, and you'll have to guess which hub they came from with practically no identifying information.  (Unless you implement the below.)


Uploading to active users is different, which is why my latest posts on the (currently defunct) DC++ forum have said that it probably can be done, but would need a rewrite of all of the User tracking internals.  (Which would probably result in each nickname on every hub being its own user, and I'd imagine that it could mess with stored users in the queue as well.)  Comparing how it could be done in NMDC to how it could be done in ADC highlights one of its benefits.

[Pothead]

Originally posted by GargoyleMT
One of the cases is uploading to two passive users - by them issuing a $RCTM to you.  If they have identical nicks, and the timing is right, you'll have two incoming connections offering the same nick, and you'll have to guess which hub they came from with practically no identifying information.  (Unless you implement the below.)

I would have thought the IP of the hub which sent the $RevConnect would be a pretty good identifier.

Originally posted by GargoyleMT
Uploading to active users is different, which is why my latest posts on the (currently defunct) DC++ forum have said that it probably can be done, but would need a rewrite of all of the User tracking internals.  (Which would probably result in each nickname on every hub being its own user, and I'd imagine that it could mess with stored users in the queue as well.)

Good point, but once it can distinguish what users are in which hub, it could then try matching them up a bit better (using share size, email and nick) instead of just grouping everyone with the same name together.
*** Edit ***
This may be a bit of topic as it wouldn't help multiple filelists, as you mention about the Queue, but it would sort out a lot of other bugs.

Originally posted by GargoyleMT
Comparing how it could be done in NMDC to how it could be done in ADC highlights one of its benefits.

Yes, but while we are waiting for ADC to take off, me might as well make what we got work better.

[GargoyleMT]

Good point, but once it can distinguish what users are in which hub, it could then try matching them up a bit better (using share size, email and nick) instead of just grouping everyone with the same name together.

That wouldn't work well with the incremental MyINFOs, now would it?  (or with Verlihub stripping tags.)  No, I don't think you could accurately decide user1 one huba is user1 on hubb.  And if you can't do it accurately, you shouldn't try.

but it would sort out a lot of other bugs.

No, I think it would introduce bugs.  And cause a whole lot of confusion for users - there's no way it can be properly explained so that no users complain about the side-effects.

Yes, but while we are waiting for ADC to take off, me might as well make what we got work better.

Sure, if you want to patch DC++'s NMDC core, feel free.  I'll be working on ADC, fixing bugs, and adding other features people want.

There are a number of non-DC++ based multi-hub clients.  I'd be interested in hearing if any of them have used the above system (of correlating connection attempts to a particular hub and using that to offer multiple shares).  If so, it'd be neat if users flocked to it.  Competition is good.