Opened at 2005-11-28T06:08:21Z
Closed at 2012-03-25T23:22:00Z
#32 closed enhancement (obsolete)
Manually reading users' away messages
Reported by: | anonymous | Owned by: | |
---|---|---|---|
Priority: | wishlist | Milestone: | |
Component: | BitlBee | Version: | |
Keywords: | Cc: | ||
IRC client+version: | Client-independent | Operating System: | Public server |
OS version/distro: |
Description
I would like a command to manually retrieve people's away messages, on ICQ and possibly other networks that support this.
Attachments (0)
Change History (14)
comment:1 Changed at 2005-11-28T08:50:49Z by
Milestone: | 1.0 |
---|
comment:2 Changed at 2005-11-28T12:10:26Z by
Shouldn't this just be a part of a WHOIS reply, like it is on every other IRC server rather then adding a seperate command for it?
comment:3 Changed at 2005-11-28T13:13:57Z by
Summary: | manually reading users' away messages → Manually reading users' away messages |
---|
Yes. Small problem, you have to wait for the reply from the IM-server before you know the away message, so the WHOIS commando should be made asynchronous if we implement this. Or see if we can request the message in advance and cache it. But I doubt if that's a good idea...
comment:4 Changed at 2005-11-30T05:23:12Z by
neither of those are very nice solutions, imo. an additional command for querying away messages might be best.
comment:5 Changed at 2005-11-30T08:44:00Z by
If you request it in advance and cache it, you'd have to request a new one all the time. Reading an outdated away message wouldn't be very nice, imho. (You could check automagically when a user changes his/her status, but what happens if the away message changes but the user went from "away" to "away"?) I think a command would be better. Agreed, it isn't very nice either, but I can't think of a better solution.
comment:6 Changed at 2006-01-16T19:56:46Z by
If "sending a command" is okay, it shouldnt be a big deal if that command just happens to be "/whois"
comment:7 Changed at 2006-01-16T20:01:07Z by
Stopgap solution:
You can use root's "info" command to get a user's away message. Downside is that it doesn't recognize if you set an alias for a given user, so you'll have to remember the user's SN whenever you want to do this.
comment:8 Changed at 2006-01-17T11:36:46Z by
It does. Just specify the nick, and not a connection. The info-command can be called with one arg (a nick) or two args (connection + handle).
comment:9 Changed at 2007-12-12T23:39:20Z by
FWIW, this works better in current development versions for at least Yahoo! and Jabber.
comment:10 Changed at 2008-06-08T17:33:12Z by
I've tried /whois in the most current version for some ICQ contacts but it it doesn't show the users' away message. Will it be available for Jabber? ICQ/AIM is going to be available soon via Jabber.
comment:11 Changed at 2008-06-08T20:54:24Z by
I've tried /whois in the most current version for some ICQ contacts but it
it doesn't show the users' away message. Will it be available for Jabber?
ICQ/AIM is going to be available soon via Jabber.
Have you heard more about this BTW? I haven't heard about this again
since it was announced in January and it's still unavailable. It'd be
more than fantastic if this really happens though.
comment:12 Changed at 2008-06-12T15:01:09Z by
Sorry, I haven't heard anything new on that topic. I even cannot telnet their server. In an interview they've said that it was just a test and there weren't any serious plans of moving to Jabber. As I've seen correctly, libpurple is able to read out the away messages. Isn't it possible to use its functions that are responsible for setting and getting the away messages?
comment:13 Changed at 2010-07-09T14:55:38Z by
Is there still no solution to read another users away message?
comment:14 Changed at 2012-03-25T23:22:00Z by
Resolution: | → obsolete |
---|---|
Status: | new → closed |
Well this is mostly possible. Only problem is that OSCAR away messages aren't read automatically (or possibly even just ICQ ones). If someone still cares about that, it's a separate bug.
Please, the milestone field is something *we* set, not you.