linuxdcpp-team team mailing list archive

[Steven Sheehy <703714@xxxxxxxxxxxxxxxxxx>]

users.xml is what doesn't seem ideal to me. Why was it a good idea to
store nick hints in a centralized hashmap that requires locking the
entire ClientManager critical section instead of pushing the nick down
into the individual User/Identity objects? Calling
ClientManager::getNicks() is a lot slower than simply retrieving a nick
from a User object. Also, users.xml looks to continue to grow and grow
with no pruning of irrelevant users, unlike loading the nick from the
queue.xml or filelist which only sticks around as long as needed.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/703714

Title:
  Add a nick hint to User

Status in DC++:
  Confirmed

Bug description:
  Currently in some areas of the GUI a CID is displayed instead of a
  nickname because the nickname is supposedly unknown and CID is the
  only way to identify the user. For example, in download queue if you
  close the program and re-open it the next day and the user you were
  downloading from is no longer online, only their CID will be shown in
  the users column. Another example is if you add a file from an old
  file list of a user who is offline, then the CID is shown in the
  download queue despite the fact that the nick is present in the file
  list name.

  A CID is not very useful to display to the end user so it would make
  more sense to store a nick as well along with it purely for display
  purposes. I propose a nick hint be added such that it contains the
  last known nickname for that user. There is a precedence for this
  already with the use of hub hints. For queue files, the nick hint
  could be added to the <Source> tag in the xml. For file lists, the
  nick hint can be extracted from the file list name. The nick hint
  would go in one of the classes in User.h, though I am not sure which
  would be most appropriate. The classes in User.h use the composite
  pattern for specialization instead of the more natural inheritance
  approach (e.g. OnlineUser should extend User, not contain it, etc), so
  it's a bit confusing which would be most appropriate for a nick hint.