Bug 233963 - Virtual users
Summary: Virtual users
Status: CONFIRMED
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: Konversation Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-10 17:05 UTC by Oswald Buddenhagen
Modified: 2013-04-15 01:38 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Oswald Buddenhagen 2010-04-10 17:05:59 UTC
Version:            (using Devel)
Installed from:    Compiled sources

in my logs/ folder, i have about 30 files with the pattern freenode_<theuser><someappendage>.log. obviously, this is totally unhelpful - these logs should be all in one file. konvi could provide two mechanisms to support this feature:
- user-specifiable "nickname transform" rules, basically a list of QRegExp::replace() expression/substitution pairs.
- if no rule applies, automatically run "/msg nickserv info $user" and evaluate the "Information on <nickname> (account <account>):" line

these "unified nicknames" could be used as a basis for other persistance-requiring features, like nick coloring (bug 209951), join notifications and such stuff.
Comment 1 Eike Hein 2010-04-10 17:12:34 UTC
Just dumping from the surrounding IRC discussion:

[17:03] <Sho_> ossi: It's a pretty complex request though, it requires a persistent way to attach data (like an alias) to a virtual user object, an extensible facility to match people encountered on IRC against those virtual users (e.g. "hostmask matches this regex" or "nickserv tells us this about user") to be able to retrieve the data, server/network sniffing because nickserv is anything but standardized and its API differs considerably from network to network, implementatons 
[17:03] <Sho_> for different networks, good network transmission queue scheduling to deal with the huge amount of traffic caused by asking nickserv for that much stuff, lots of state tracking for the communication with nickserv and a way to deal with the latency issue of the data not being available immediately (e.g. buffering or retrofitting logs)
[17:04] <Sho_> ossi: konversation has all of the above to some degree, but not quite to the level that it would make your request trivial, and even the best possible implementation will most likely be brittle given the realities of IRC