From: Richard Bullington-M. <rbu...@pk...> - 2004-09-01 01:24:51
|
First off, I'd like to thank everyone for creating such a great IM client. GAIM is the best all-around IM client I've had the pleasure to work with. In other Jabber clients, such as Exodus, it's possible to query the idle time of others logged in to the network. Gaim seems to lack this feature currently. AOL IM clients who are idle show the amount of time they have been idle in the status line right below the name. It would be nice if the same thing happened for Jabber clients. At a minimum, the idle time should be available in the Jabber Profile screen launched from the "Get Info" context menu. Is this something that someone is working on now, or planning to work on? If not, I'd be happy to start an RFE in the tracking system. I might be able to help a bit on a patch, too. -- Richard Bullington-McGuire, Managing Partner, PKR Internet, LLC Email: rbu...@pk... Web: http://pkrinternet.com/ Phone: +1 (703) 271 0607 Fax: +1 (703) 271 0580 PGP key IDs: RSA: 0x9386230 DH/DSS: 0xDAC3028E |
From: Nathan W. <fac...@fa...> - 2004-09-01 23:00:21
|
Jabber's current method for obtaining idle time doesn't jive well with Gaim's idle reporting system. To have idle times show up the way they do for AIM, I'd have to constantly poll every jabber buddy in your buddy list. I flat out refuse to do this. Having them show up in the profile window would require me to be able to update the profile window once it's already been displayed, since the idle time request is separate from the profile request. We could have yet another right-click option for buddies to get their idle time only, but that seems kind of bloated to me. Everyone can feel free to convince me otherwise on this point. -Nathan Richard Bullington-McGuire wrote: > > First off, I'd like to thank everyone for creating such a great IM > client. GAIM is the best all-around IM client I've had the pleasure to > work with. > > In other Jabber clients, such as Exodus, it's possible to query the idle > time of others logged in to the network. Gaim seems to lack this feature > currently. > > AOL IM clients who are idle show the amount of time they have been idle > in the status line right below the name. It would be nice if the same > thing happened for Jabber clients. At a minimum, the idle time should be > available in the Jabber Profile screen launched from the "Get Info" > context menu. > > Is this something that someone is working on now, or planning to work > on? If not, I'd be happy to start an RFE in the tracking system. I might > be able to help a bit on a patch, too. > > > |
From: Matthew K. <kel...@po...> - 2004-09-02 01:23:47
|
On Wed, 2004-09-01 at 19:00, Nathan Walp wrote: > Jabber's current method for obtaining idle time doesn't jive well with > Gaim's idle reporting system. Not knowing how Gaim reports idle time, but knowing how Jabber supplies them, couldn't you have a minutely (or even 2 or 5 minutely polling alarm that updates the Gaim "idle times"? I agree that the constant polling is not even slightly a good idea, but I know Gaim supports alarms (do something, tell me when a minute has passwd, do something, tell me...) at least for plugins, so I assume it supports them for protocol plugins too. Again, I don't know how Gaim handles the reporting so this may not be efficiently feasible- Just a thought. -- Matthew Keller signat-url: http://mattwork.potsdam.edu/signat-url/ "No one ever says, 'I can't read that ASCII E-mail you sent me.'" |
From: Ethan B. <ebl...@cs...> - 2004-09-02 05:25:18
|
Matthew Keller spake unto us the following wisdom: > On Wed, 2004-09-01 at 19:00, Nathan Walp wrote: > > Jabber's current method for obtaining idle time doesn't jive well with= =20 > > Gaim's idle reporting system. >=20 > Not knowing how Gaim reports idle time, but knowing how Jabber supplies > them, couldn't you have a minutely (or even 2 or 5 minutely polling > alarm that updates the Gaim "idle times"? I agree that the constant > polling is not even slightly a good idea, but I know Gaim supports > alarms (do something, tell me when a minute has passwd, do something, > tell me...) at least for plugins, so I assume it supports them for > protocol plugins too. Again, I don't know how Gaim handles the reporting > so this may not be efficiently feasible- Just a thought. So, speaking out of any specific protocol or implementation context here, and not even necessarily on this topic, except that it was brought up ... In network protocols, Polling is Bad. Always. There are _occa- sionally_ reasons why Something Else is Worse, and so polling is the right answer -- but not very often at all. To give you an idea of how bad polling is, when the TCP protocol was designed, it was designed with a keepalive mechanism. In other words, a way to force polling of the opposite end. The standard also says that this mechanism MUST NOT default to a polling interval of less than _two hours_. Not two min- utes, or twenty minutes, but two hours. That's not to say that IM protocols aren't full of hideous polling and time-triggered but predictable updates; in fact, I implemented a polling mechanism for IRC to provide the pseudo-buddy list we currently have (or, more accurately, reimplemented). However, these sorts of behaviors are best avoided, and should be considered only as a last-ditch effort to provide a feature that can be provided in no other way and that is That Important. (e.g., NOT like buddies on IRC, which I think is a stupid idea.) The moral of the story is, if jabber idle times have to require a manu- ally triggered request/response in order to avoid polling, I'm in favor of such a mechanism. (And I realize that Mr. Keller also qualified his mention of polling by saying it is bad ... this topic just seems to come up often (more often on IRC).) Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Matthew K. <kel...@po...> - 2004-09-02 12:59:06
|
On Thu, 2004-09-02 at 01:25, Ethan Blanton wrote: > (And I realize that Mr. Keller also qualified his <...snip...> I feel old. I had a student call me "professor" this morning, and now "mister". Argh. Anyhow, I completely understand the leeriness of polling. Would the following be an acceptable compromise? Again- Not knowing how Gaim deals with these things, another thought I had was have Gaim clients logged into Jabber servers inform other Gaim clients logged into Jabber servers what their idle time is (c2s)- Although you can change the Jabber "Resource", by default in Gaim it's set to "Gaim" and could be used as a filter - Thus the client could heartbeat to the other clients whose "Resource" was "Gaim", periodically. The receiving side could then "do the right thing" with the heartbeat data. It could be a protocol pref, if there was the desire to turn it on and off. Not trying to preach- Just academically interested at what The Best solution would be, based on the posit that we can't change the Jabber servers (I know we can, and I know there are things in the works to do that- I'm just interested in a good, efficient, pure in-Gaim solution, that may be modeled by other clients as well). -- Matthew Keller signat-url: http://mattwork.potsdam.edu/signat-url/ "No one ever says, 'I can't read that ASCII E-mail you sent me.'" |
From: Dave W. <ka...@us...> - 2004-09-02 13:51:23
|
On Thu, 2 Sep 2004, Matthew Keller wrote: > Again- Not knowing how Gaim deals with these things, another thought I > had was have Gaim clients logged into Jabber servers inform other Gaim > clients logged into Jabber servers what their idle time is (c2s)- > Although you can change the Jabber "Resource", by default in Gaim it's > set to "Gaim" and could be used as a filter - Thus the client could > heartbeat to the other clients whose "Resource" was "Gaim", > periodically. The receiving side could then "do the right thing" with > the heartbeat data. I may not be fully clued in this morning; I don't see how sending a heartbeat to other clients with a specific resource is much different than polling. I could see possibly a modification of this to where an idle update is sent once idleness is achieved and then 5 or 10 minutes afterward; something in my head tells me that's not a good idea either. I think that one should be very careful of embrace and extend. At least one of the devs, possibly more, have said recently: (paraphrasing) in the case of commercial messenger protocols that the goal is (protocol-wise) to behave like the official client as much as possible. The same should be true of protocols with an official standard: if they say that the way to get the idle time of a resource is to poll that resource then we do so as inexpensively as possible. In this case, I think an account action and placing it in the context menu for jabber is the right thing for respecting the networks, the protocol and the maintenance of code. --dw |
From: Andrew S. <gt...@ma...> - 2004-09-02 15:22:02
|
On Thu, 2004-09-02 at 09:51, Dave West wrote: > I think that one should be very careful of embrace and extend. At least > one of the devs, possibly more, have said recently: (paraphrasing) in > the case of commercial messenger protocols that the goal is (protocol-wise) > to behave like the official client as much as possible. The same should be > true of protocols with an official standard: if they say that the way to > get the idle time of a resource is to poll that resource then we do so > as inexpensively as possible. In this case, I think an account action and > placing it in the context menu for jabber is the right thing for > respecting the networks, the protocol and the maintenance of code. The truth of the matter is that the jabber protocol doesn't have a standard for idle time. The current JEP for it isn't standards track and is meant more to describe how things are already being done. If somebody started altering the code to send out idle information, and then other clients started to pick up on this, it wouldn't have any real effect on the standard other than to posibly invalidate a JEP that says can be invalidated at any time. -- Andrew Sayman <gt...@ma...> |
From: Tim R. <om...@ho...> - 2004-09-04 04:22:37
|
> > >On Wed, 2004-09-01 at 19:00, Nathan Walp wrote: > > >>Jabber's current method for obtaining idle time doesn't jive well with >>Gaim's idle reporting system. >> 1. I want to make adding to the dialog work eventually. It would be nice for Yahoo!, well probably most protocols really. But since eventually != now, I won't go into detail about why this would be better. 2. For pretty much every protocol, we send some kind of request, and then display a dialog with both the responce to the request, and some information we already had. Since the dialog doesn't provide instand feedback (although I'd like it to, see 1), I don't see what's wrong with simply not displaying it until we have all the info. We do this for Yahoo! now (fetch the profile, parse it, then fetch the profile picture if there is one, and then display it all). --Tim |
From: Nathan W. <fac...@fa...> - 2004-09-04 06:48:09
|
Tim Ringenbach wrote: >> >> >> On Wed, 2004-09-01 at 19:00, Nathan Walp wrote: >> >> >>> Jabber's current method for obtaining idle time doesn't jive well >>> with Gaim's idle reporting system. >>> > > 1. I want to make adding to the dialog work eventually. It would be nice > for Yahoo!, well probably most protocols really. But since eventually != > now, I won't go into detail about why this would be better. > > 2. For pretty much every protocol, we send some kind of request, and > then display a dialog with both the responce to the request, and some > information we already had. Since the dialog doesn't provide instand > feedback (although I'd like it to, see 1), I don't see what's wrong with > simply not displaying it until we have all the info. We do this for > Yahoo! now (fetch the profile, parse it, then fetch the profile picture > if there is one, and then display it all). The problem is that you have a reasonable assurance that your requests for information on Yahoo will come back with something, be it the information you requested, or an error. While the jabber spec requires we get something back, we don't always get something back. I don't want to sit around waiting for something that won't happen. There's a patch in the tracker I need to look at that does basically what I want. It implements a timeout, so we'll show the user whatever pieces we get back within a certain amount of time (yet to be decided). I figure that's a good enough solution until we gain the ability to update the dialog. -Nathan |
From: Tim R. <om...@ho...> - 2004-09-04 08:44:19
|
Nathan Walp wrote: > The problem is that you have a reasonable assurance that your requests > for information on Yahoo will come back with something, be it the > information you requested, or an error. While the jabber spec > requires we get something back, we don't always get something back. I > don't want to sit around waiting for something that won't happen. Ah. I didn't know that. Good point. --Tim |
From: Richard Bullington-M. <rbu...@pk...> - 2004-09-02 13:58:37
|
On Wed, 1 Sep 2004, Nathan Walp wrote: > Jabber's current method for obtaining idle time doesn't jive well with Gaim's > idle reporting system. > > To have idle times show up the way they do for AIM, I'd have to constantly > poll every jabber buddy in your buddy list. I flat out refuse to do this. Yeah, that would be ugly. > Having them show up in the profile window would require me to be able to > update the profile window once it's already been displayed, since the idle > time request is separate from the profile request. What if you made the profile request and idle time request back to back, and aggregated the results? > We could have yet another right-click option for buddies to get their idle > time only, but that seems kind of bloated to me. Everyone can feel free to > convince me otherwise on this point. The separate query option is how Exodus does it. It seems a bit ugly to me, but it does work. There is another, fairly efficient option for displaying idle for buddies that have gone to an Away state. 1. GAIM learns that a Jabber buddy has gone away 2. GAIM queries Jabber for the buddy's idle time 3. GAIM sets an internal alarm that updates the idle time each minute without going across the network to ask again 3. When GAIM learns that the buddy is Available again, it cancels the timer. -- Richard Bullington-McGuire, Managing Partner, PKR Internet, LLC Email: rbu...@pk... Web: http://pkrinternet.com/ Phone: +1 (703) 271 0607 Fax: +1 (703) 271 0580 PGP key IDs: RSA: 0x9386230 DH/DSS: 0xDAC3028E |
From: Evan S. <ev...@dr...> - 2004-09-02 20:13:16
|
On Sep 2, 2004, at 8:58 AM, Richard Bullington-McGuire wrote: > 1. GAIM learns that a Jabber buddy has gone away > 2. GAIM queries Jabber for the buddy's idle time > 3. GAIM sets an internal alarm that updates the idle time each minute > without going across the network to ask again > 3. When GAIM learns that the buddy is Available again, it cancels the > timer. > Better than that, why not: 1. Gaim learns a Jabber buddy has gone away 2. Gaim queries Jabber for the buddy's idle time, and stores the time the buddy went idle 3. If the user requests an idle time display in whatever form, determine the time from the stored time until -now-. This has the advantage of not needing a periodic poll for every away buddy. Of course, it's still not an accurate measure - one can be away without being idle, or idle without being away, or go away and become idle and then become unidle without coming back from away, or.... so I think it'd be a bit misleading. -Evan |
From: Luke S. <lsc...@us...> - 2004-09-02 20:34:57
|
On Thu, Sep 02, 2004 at 03:13:11PM -0500, Evan Schoenberg wrote: > > On Sep 2, 2004, at 8:58 AM, Richard Bullington-McGuire wrote: > > >1. GAIM learns that a Jabber buddy has gone away > >2. GAIM queries Jabber for the buddy's idle time > >3. GAIM sets an internal alarm that updates the idle time each minute > >without going across the network to ask again > >3. When GAIM learns that the buddy is Available again, it cancels the > >timer. > > > > Better than that, why not: > > 1. Gaim learns a Jabber buddy has gone away > 2. Gaim queries Jabber for the buddy's idle time, and stores the time > the buddy went idle > 3. If the user requests an idle time display in whatever form, > determine the time from the stored time until -now-. > > This has the advantage of not needing a periodic poll for every away > buddy. Of course, it's still not an accurate measure - one can be away > without being idle, or idle without being away, or go away and become > idle and then become unidle without coming back from away, or.... so I > think it'd be a bit misleading. exactly, it would be misleading and so i'm not a fan of this idea (or its predecessor). luke > > -Evan > |
From: Richard Bullington-M. <rbu...@pk...> - 2004-09-02 23:26:42
|
On Thu, 2 Sep 2004, Evan Schoenberg wrote: > Better than that, why not: > > 1. Gaim learns a Jabber buddy has gone away > 2. Gaim queries Jabber for the buddy's idle time, and stores the time the > buddy went idle > 3. If the user requests an idle time display in whatever form, determine the > time from the stored time until -now-. Right. That's what I meant in the first place :) So much smarter than incrementing a minute counter each minute. > This has the advantage of not needing a periodic poll for every away buddy. > Of course, it's still not an accurate measure - one can be away without being > idle, or idle without being away, or go away and become idle and then become > unidle without coming back from away, or.... so I think it'd be a bit > misleading. It might be useful to know the time since the away status was set. Then again, given the other comments in this thread, it's not clear that there is a clean and easy standards-compatible way to do this with Jabber yet. -- Richard Bullington-McGuire, Managing Partner, PKR Internet, LLC Email: rbu...@pk... Web: http://pkrinternet.com/ Phone: +1 (703) 271 0607 Fax: +1 (703) 271 0580 PGP key IDs: RSA: 0x9386230 DH/DSS: 0xDAC3028E |
From: Sean E. <sea...@gm...> - 2004-09-02 20:44:49
|
On Thu, 2 Sep 2004 06:51:15 -0700 (PDT), Dave West <ka...@us...> wrote: > I think that one should be very careful of embrace and extend. At least > one of the devs, possibly more, have said recently: (paraphrasing) in > the case of commercial messenger protocols that the goal is (protocol-wise) > to behave like the official client as much as possible. The same should be > true of protocols with an official standard: if they say that the way to > get the idle time of a resource is to poll that resource then we do so > as inexpensively as possible. In this case, I think an account action and > placing it in the context menu for jabber is the right thing for > respecting the networks, the protocol and the maintenance of code. I agree 100%. Now, if only there were some sort of *extensible* messaging and presence protocol... that would rule. -s. |
From: alexd <tro...@bl...> - 2004-09-02 22:25:04
|
On Thu, 2004-09-02 at 16:44 -0400, Sean Egan wrote: > Now, if only there were some sort of *extensible* > messaging and presence protocol... that would rule. There is. It's called gaim ;-) alexd -- ale.cx |
From: Nathan W. <fac...@fa...> - 2004-09-03 00:20:07
|
Andrew Sayman wrote: > On Thu, 2004-09-02 at 09:51, Dave West wrote: > >>I think that one should be very careful of embrace and extend. At least >>one of the devs, possibly more, have said recently: (paraphrasing) in >>the case of commercial messenger protocols that the goal is (protocol-wise) >>to behave like the official client as much as possible. The same should be >>true of protocols with an official standard: if they say that the way to >>get the idle time of a resource is to poll that resource then we do so >>as inexpensively as possible. In this case, I think an account action and >>placing it in the context menu for jabber is the right thing for >>respecting the networks, the protocol and the maintenance of code. > > > The truth of the matter is that the jabber protocol doesn't have a > standard for idle time. The current JEP for it isn't standards track and > is meant more to describe how things are already being done. If somebody > started altering the code to send out idle information, and then other > clients started to pick up on this, it wouldn't have any real effect on > the standard other than to posibly invalidate a JEP that says can be > invalidated at any time. We don't make defacto standards in Jabber. We design a protocol, come up with a protocol document, submit it as a JEP, and come up with a working implementation. If I do anything other than that, I'm going to get booed out of the JSF. I'm planning on doing all of the above steps once 1) I have more free time and 2) pubsub stabilizes, since it will need to be pubsub based. As for everyone else suggesting poll-but-gently options: NO. Not no way, not no how. You will not convince me to poll, and I will not let in any code that polls. Asking once when they go away, and assuming things from there on out is quite possibly the dumbest thing i've heard this week, and believe me, it's been a bad week for that sort of thing. You're not in good company. </rant> -Nathan |
From: Ethan B. <ebl...@cs...> - 2004-09-03 02:01:14
|
Nathan Walp spake unto us the following wisdom: > As for everyone else suggesting poll-but-gently options: NO. Not no=20 > way, not no how. You will not convince me to poll, and I will not let=20 > in any code that polls. Asking once when they go away, and assuming=20 > things from there on out is quite possibly the dumbest thing i've heard= =20 > this week, and believe me, it's been a bad week for that sort of thing.= =20 > You're not in good company. I love you, Nathan. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Richard Bullington-M. <rbu...@pk...> - 2004-09-05 22:49:35
|
On Thu, 2 Sep 2004, Nathan Walp wrote: > Asking once when they go away, and assuming things from there on > out is quite possibly the dumbest thing i've heard this week, and believe me, > it's been a bad week for that sort of thing. You're not in good company. Is there then no smart way to do it given the current universe of Jabber clients and servers out there? Is the only reasonable way forward to propose a standard way to do things and hash it in a JEP? I'm wondering what the Exodus project did to enable idle time reporting. (Software development often involves considering a bunch of dumb ideas until one finds the most practical way to proceed.) -- Richard Bullington-McGuire, Managing Partner, PKR Internet, LLC Email: rbu...@pk... Web: http://pkrinternet.com/ Phone: +1 (703) 271 0607 Fax: +1 (703) 271 0580 PGP key IDs: RSA: 0x9386230 DH/DSS: 0xDAC3028E |