Why not making Dwonload source by email?
What I’m saying is that, the problem of changing nicks is decrementing a source in queue(forcing to do "Match queue" or another search), so as we change email least often as we change nick this could solve the problem...
It could also be created a new right mouse button option that would give the nick “history� (done client-client)...
Advantage:
Allowing us to change the nick as often as we want, without interfering with others...
Anyway is a suggestion...
Best regards,
[PT]Devilishly
Why not making dwl source by email? (...)
Moderator: Moderators
-
- Posts: 96
- Joined: 2003-04-18 05:57
- Location: Oporto, Portugal
- Contact:
-
- Forum Moderator
- Posts: 587
- Joined: 2003-05-07 02:38
- Location: Sweden, Linkoping
-
- Posts: 96
- Joined: 2003-04-18 05:57
- Location: Oporto, Portugal
- Contact:
Well, that's not really the point (or the objective of this implementation...)...
Using the email is (in my point of view) the easiest way to modify the way dc works in matter of “Queue�...
Off course they could change email so queues won’t get them, but isn’t that also possible by changing nick? Anyway, using this would give “freedom� to users changing nicks as they want, without inferring with other user’s queues...
The best way of doing this would be something like an internal unique number, so that changing nicks or emails wouldn’t interfere with queues...
Best regards,
[PT]Devilishly
Using the email is (in my point of view) the easiest way to modify the way dc works in matter of “Queue�...
Off course they could change email so queues won’t get them, but isn’t that also possible by changing nick? Anyway, using this would give “freedom� to users changing nicks as they want, without inferring with other user’s queues...
The best way of doing this would be something like an internal unique number, so that changing nicks or emails wouldn’t interfere with queues...
Best regards,
[PT]Devilishly
Why not do something more direct, such as create a unique user ID (perhaps IP + current time [including seconds]...I think that'd be unique enough so as not to mistake one user for another), and then passing that between clients. Store it in the XML file so that a user would have to erase the XML or manually change the unique ID (which would then force them to reboot the client to reload their new one). Just thoughts.
-
- Forum Moderator
- Posts: 587
- Joined: 2003-05-07 02:38
- Location: Sweden, Linkoping
The problem is that a protocol extension would be needed to make this work, as using a currently existing field would cause other problems. The only field I would even *consider* using as a holder for the unique ID is the Version field, and the significant fault in that is that so many people use 1.0091 that it'd be impossible to distinguish them from each other, and would flaw the desired results significantly, too much IMO to be really useful.
- Gratch06
- Gratch06
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
I think you're looking for something like GUID, Gratch... A few of the next-gen protocol proposals include it, and it will likely be in some form in the next protocol.
You could do it in the current one, but there's no nice way to include it in a search result, where files are often queued. Client to client exchanges are possible, but a bit ugly.
(Oh, and $Version is not broadcast, so it wouldn't be useful without a modified hub.)
You could do it in the current one, but there's no nice way to include it in a search result, where files are often queued. Client to client exchanges are possible, but a bit ugly.
(Oh, and $Version is not broadcast, so it wouldn't be useful without a modified hub.)