Why not making dwl source by email? (...)

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

Moderator: Moderators

Locked
[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Why not making dwl source by email? (...)

Post by [PT]Devilishly » 2003-11-12 07:09

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

joakim_tosteberg
Forum Moderator
Posts: 587
Joined: 2003-05-07 02:38
Location: Sweden, Linkoping

Post by joakim_tosteberg » 2003-11-12 09:33

I don't think all people using dc++ want to publish their email to public which they'll have to do if I've understood your feature request right. And what make you belive that there not are people that just write som random mail adress and uses that and also perhaps change it every now and then ?

[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Post by [PT]Devilishly » 2003-11-12 11:22

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

Gratch06
Posts: 141
Joined: 2003-05-25 01:48
Location: USA

Post by Gratch06 » 2003-11-12 11:27

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.

joakim_tosteberg
Forum Moderator
Posts: 587
Joined: 2003-05-07 02:38
Location: Sweden, Linkoping

Post by joakim_tosteberg » 2003-11-12 13:29

That was a better idea Gratch06 :D :wink:

Gratch06
Posts: 141
Joined: 2003-05-25 01:48
Location: USA

Post by Gratch06 » 2003-11-12 13:46

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

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

Post by GargoyleMT » 2003-11-13 12:36

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.)

Locked