Dynamic presence settings

[Mats]

From Zbiggy:

I've got an idea for another suggestion: referring to the last one,
(presence-related), got an idea for automatic status change according to the
"level of busyness".

Idea is very simple: let's suppose, you have status "ready to chat". Now, if
you have one chat window opened, the status automatically gets "one level
down" - to "available". If you've got two chat window opened (or one chat,
one conference) - it drops "two levels down" - to "away". If you have three
chat windows opened... got it already? Status is now "DnD"... and so on.

Of course, if your "starting status" was "away" - by one chat window opened
it drops to "DnD". When you were busy enough to set "away" - it means, that
doing something and having one chat in addition, you cannot answer another
one. When you're closing the chat/conference windows - the status' getting
back to the "starting one".

In presented way one doesn't have to modify his present status "by hand"
anymore. What do you think?

[Mats (matsben)]

Sounds perhaps a bit too ad-hoc, but possible.

[sander (s-devrieze)]

This can be done with the busy presence state but not with the Away state. Away is meant only for when you are physically from the computer.

In the Auto Away section:

Busy when (active chat sessions): <number field>
   Message: <message field>

balloon text: When you have <number> or more active chat sessions, presence state will be automatically changed to Busy.

details:
* user should still be able to manually change his presence state
* there should be a timer interval before the Busy presence state is removed again after the number of active sessions decreased under the limit
* this timer interval should be shorter when the number of active chat sessions decreased with 2 under the limit, even more with 3 etc
* the definition of an active chat session should change when the user sets a higher value in the preferences (e.g. when he sets 3 there should be activity each 30 secs for a session to be marked as active, but if he sets 6 this number will be 60 secs. PS: I'm not sure if these are the best values!). This should be done because if there are more active chat sessions it takes more time for the user to switch between them because it gets more difficult to follow the different discussions.
* do not include chatroom sessions or whiteboard sessions

For example:
setting is 4, so an active chat session is defined as activity in the last 40 secs

cases:
1) 4 sessions, but only 3 active==>no auto-Busy
2) 4 active sessions==>auto-Busy
3) 5 active sessions==>still auto-Busy
4) 4 active sessions==>still auto-Busy
5) 3 active sessions==>still auto-Busy + start timer (1 minutes)
6) 2 active sessions (15 secs later!) ==>still auto-Busy + change timer value to 45 / 3 == 15 secs
7) 1 active session (6 secs later!) ==>still auto-Busy + change timer value to 9 / 3 == 3 secs
8) 1 active session (3 secs later!) ==>remove auto-Busy (so this is 24 secs after the timer was started)

[Zbiggy (zb-ispid)]

"This can be done with the busy presence state but not with the Away state. Away is meant only for when you are physically from the computer."

I think, it's a kind of recommendantion rather than formal prohibition.

In my opinion it's just another "grade" in the status levels, which has just such name; sometimes it's replaced with: "be back soon", which better reflects, that such status is just "less than `available' - but still more than 'DnD' ". So, I can't see a reason to such very "formal" approach.

BTW: "be back soon" doesn't necessarily mean, that someone is physically away from his machine; it should rather be understood as "a bit busy at the moment - but soon be available again".

[Mats (matsben)]

Just for the record, you mean to set the users "global" presence, right.
An alternative would be to send "directed presence" to the contacts
you are chatting with.
I don't they are "sticky" so they'll be changed/removed next time you
(manually) set the status.
In any case http://www.xmpp.org/extensions/xep-0085.html is meant to
be functionally be doing what you want.

[sander (s-devrieze)]

2007/11/19, Mats <email address hidden>:
> Just for the record, you mean to set the users "global" presence, right.
> An alternative would be to send "directed presence" to the contacts
> you are chatting with.

Yes, that may be a good idea: only send the Busy presence state to
other contacts and leave the current state for the active chat
sessions. This may reduce confusion, e.g. "Oh, you are busy, then we
can talk about this later if you want-->no, that's because I'm busy
with you :-) Please, go on!"

> I don't they are "sticky" so they'll be changed/removed next time you
> (manually) set the status.
> In any case http://www.xmpp.org/extensions/xep-0085.html is meant to
> be functionally be doing what you want.

yes

--
Mvg, Sander Devrieze.

[sander (s-devrieze)]

2007/11/19, Zbiggy <email address hidden>:
> "This can be done with the busy presence state but not with the Away
> state. Away is meant only for when you are physically from the
> computer."
>
> I think, it's a kind of recommendantion rather than formal prohibition.

I know people use this sometimes in another way. Though, for this
feature I think there only should be set the Busy state. Either you
are busy and you can't answer other incoming chats (besides in case of
urgency), or you can still handle some more chat sessions. In the
first case your presence state should be automatically changed to
Busy, and in the latter it can stay the same.

Another advantage of only using the Busy state for this feature is
that it will make things less complicated for Mats B-)

--
Mvg, Sander Devrieze.

[Mats (matsben)]

My picture of it:
1) Place it among the Auto Away settings
2) Try to apply those settings to each hidden chat tab and treat "hidden" as inactivity
3) But send directed presence to that user instead of global presence

This way we can "reuse" prefs and only need a new checkbutton

[sander (s-devrieze)]

2007/11/20, Mats <email address hidden>:
> My picture of it:
> 1) Place it among the Auto Away settings
> 2) Try to apply those settings to each hidden chat tab and treat "hidden" as inactivity

I don't see what you mean here.

> 3) But send directed presence to that user instead of global presence

I think you only should send the Busy presence state to *all* contacts
*but* the contacts with whom you're actively chatting. In this way:
1) all contacts with whom you are *not* actively chatting will see
they don't have to bother you for some time, and
2) all contacts with whom you *are* actively chatting will not get the
impression that they are bothering you and that they should stop
chatting with you.

--
Mvg, Sander Devrieze.

[Mats (matsben)]

Now there. It is now just a simple checkbutton in the auto-away settings. In short, hidden tags are treated as if the user is completely inactive (no mouse or keyboard), and the settings are reused. This is in line with "minimal" UI which we want to have. There is also a tooltip for this. I can see one alternative: apply auto-away settings on hidden tabs even if they have not be switched on for global settings.

[Mats (matsben)]

> I think you only should send the Busy presence state to *all* contacts
> *but* the contacts with whom you're actively chatting.

This is not good XMPP. Think of 200 online contacts and I chat with one. Then I would need to send 200 presence stanzas. The whole idea with presence is that it is the *server* that dispatches presence.
Well, I could send global presence and then a new presence to the one I'm chatting with. In that case it would get two presence stanzas.

If you are really busy chatting with a contact just set the global presence state, and let the contact you are active with that it wasn't for him or her.

[Zbiggy (zb-ispid)]

"An alternative would be to send "directed presence" to the contacts
you are chatting with."

It will be contrary to the logic of the proposed solution. It's simply misunderstanding.

My idea was to let the *other potential* "chatters" know, that I can be busy (because I've got 2 chats already) - and the people, to whom I'm talking now, doesn't necessarily need to be interested in my present status, exactly because they're chatting with me already.

[Mats (matsben)]

I think I had the logic on my side ;-)
Anyway, "potential" chatters should be notified by the usual status
settings, but my thought was
that if you have an open chat with someone you are expecting more
prompt responses,
and it would therefore be useful if you got an away or xa on hidden
tabs which says that you wont be getting an active response right now.

Or am I wrong?
I can see your logic as well...
Seems we both have a point...

/Mats

On 11/22/07, Zbiggy <email address hidden> wrote:
> "An alternative would be to send "directed presence" to the contacts
> you are chatting with."
>
> It will be contrary to the logic of the proposed solution. It's simply
> misunderstanding.
>
> My idea was to let the *other potential* "chatters" know, that I can be
> busy (because I've got 2 chats already) - and the people, to whom I'm
> talking now, doesn't necessarily need to be interested in my present
> status, exactly because they're chatting with me already.
>
> --
> Dynamic presence settings
> https://bugs.launchpad.net/bugs/163749
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Zbiggy (zb-ispid)]

Hmmm... the point of the proposed solution was to set automatically the status, with the intention to inform about current "level of busyness" those, with whom you're not talking *yet* ("to the world", saying it shortly). To avoid setting the status manually over and over again.

The status, which will be seen by the ones, to whom you're talking at the moment, it's a secondary question in my opinion - just because every misunderstandings (if any) can be cleared during talk; exactly because you're in direct chat with them already.

(...or perhaps I don't get it?).

[sander (s-devrieze)]

Zbiggy and me are right: it makes no sense to implement what you suggest :P

Some arguments:
1) hypothetical conversation:
me: hey, what do you think about this?
stpeter: sorry, I'm too busy right now
me: why don't you change your presence to Busy then?
stpeter: I was too busy to change it...

So the feature that Zbiggy proposes is that Coccinella should help people like stpeter by automating changing the presence when you are busy chatting with several people. Also, instead of globally changing the presence, this presence should only be send to people with whom stpeter is *not* actively chatting. Also, all people that become available in the meantime should be send the temporary Busy presence. Also, Coccinella should automatically undo this auto-Busy presence when stpeter is not busy anymore for some time (according to the algorithm).

Advantages:
* stpeter will save time as he don't need to change his presence manually to Busy and back to Online afterwards
* stpeter will save time as he don't need to explain people like me he is busy with other chats
* stpeter will save time as he don't need to explain the contacts with whom he is actively chatting that they aren't bothering him (this may happen if he changes the global presence to Busy which will also be seen by the contacts with whom he is actively chatting)
* stpeter's contacts will save time for the same reasons
==>core advantage: time saver == money saver (as: time == money ;-) )

2) too much presence stanza's argument: This XEP is made to reduce the number of duplicate stanzas (it will be supported in next ejabberd and AFAIR Psi and some other Jabber clients already support it): http://www.xmpp.org/extensions/xep-0033.html

[Zbiggy (zb-ispid)]

"The status, which will be seen by the ones, to whom you're talking at the moment..."

"_TO_ the ones" - I meant, of course.

[Zbiggy (zb-ispid)]

Seems, I'm somewhat sleepy today. :] Sorry.

(Is it possible to delete one's own post?)

[Zbiggy (zb-ispid)]

"this presence should only be send to people with whom stpeter is *not* actively chatting"

I'm not sure: doesn't it imply a "global" presence change anyway? Looks for the simplest solution to me...

[sander (s-devrieze)]

"I'm not sure: doesn't it imply a "global" presence change anyway? Looks for the simplest solution to me..."

Yes, it's probably the simplest, but not the best. These people may get the feeling they are bothering you and that you changed your presence state because you want to get rid of them. To avoid possible misunderstandings like this it is best to not send the Busy presence state to people with whom you are actively chatting.

[Zbiggy (zb-ispid)]

So, your idea is to change global presence in the way I proposed - and additionally to maintain actual status seen by "present chatters", by send to them "directed presence"? Right?

[sander (s-devrieze)]

2007/11/23, Zbiggy <email address hidden>:
> So, your idea is to change global presence in the way I proposed - and
> additionally to maintain actual status seen by "present chatters", by
> send to them "directed presence"? Right?

I'm not sure if this is possible; if you change your global presence
state, *all* contacts will get it. So, it may be necessary to send
directed presence to all your other online contacts but not the
contacts with whom you are actively chatting. Also other contacts that
become online in the meantime should get this directed presence. As
this will generate lot's of XML as Mats said, XEP-033 support will be
a welcome feature (see Bug #144831 ).

--
Mvg, Sander Devrieze.

[Zbiggy (zb-ispid)]

I'm not sure, how in practice "directed presence" works; but from what you wrote, seems to me, that it's rather simple: the contacts, which are receiving a presence "directed to them" will see other status, than the "global" one.

So, I really can't see a problem to change global status first, and then to send "directed presence" just to "present chatters". And that "directed presence" should be a status level, which has been set *before* global status change; as the result the chatters won't notice any status change.

Am I wrong?

[sander (s-devrieze)]

2007/11/23, Zbiggy <email address hidden>:

> So, I really can't see a problem to change global status first, and then
> to send "directed presence" just to "present chatters". And that
> "directed presence" should be a status level, which has been set
> *before* global status change; as the result the chatters won't notice
> any status change.
>
> Am I wrong?

No, but in that case these contacts may get annoyed or confused by
your 2 presence changes. Using directed presence to all *other*
contacts combined with XEP-0033 support is the best solution AFAICS.

--
Mvg, Sander Devrieze.

[Zbiggy (zb-ispid)]

"in that case these contacts may get annoyed or confused by your 2 presence changes."

But are you sure, that they will notice a change which will last, say, about 100 msec approximately? And even in case - that they really can be annoyed by such short "blink" in the status?

I suppose, that they rather will hear some sound (if they have sound status change signalling), and before they will look at the status indicator, it'll be set back to previous state... so, I'm not really sure, is the more complicated solution worth an effort.

Additionally: if "directed presence" is quite independent of the global status (I don't know that) - it could be then sent even *before* global status change... and if not - see above.

[sander (s-devrieze)]

2007/11/23, Zbiggy <email address hidden>:
> "in that case these contacts may get annoyed or confused by your 2
> presence changes."
>
> But are you sure, that they will notice a change which will last, say,
> about 100 msec approximately? And even in case - that they really can be
> annoyed by such short "blink" in the status?
>
> I suppose, that they rather will hear some sound (if they have sound
> status change signalling), and before they will look at the status
> indicator, it'll be set back to previous state...

Yes, all kind of notifications: sound, blink, presence change line,
Growl (like) notifications, and so forth.

> so, I'm not really
> sure, is the more complicated solution worth an effort.

XEP-0033 should be implemented anyway (because of the overall
advantages, see e.g. Badlop's blog:
http://badlop.blogspot.com/search/label/jabber ). So, why not
implement this first. ok, it may take longer before the Busy feature
is operational, but when it's operational fewer code restructures will
be needed in the long run and it will work perfectly.

> Additionally: if "directed presence" is quite independent of the global
> status (I don't know that) - it could be then sent even *before* global
> status change... and if not - see above.

I don't think that is possible. I guess global presence will overwrite
all directed presence states. @Mats: correct me if I'm wrong.

--
Mvg, Sander Devrieze.

[Mats (matsben)]

OK, I'm trying to digest your opinions here. You both agree that the present implementation is crap, so I perhaps can archive it for any future use by having it set config() 0.
First sending a global presence change whenever you get a new chat, and then directed presence to each with whom your are actively chatting with can be a bit too annoying for them.

If you think of XEP-0033 I don't think this actually solves it since you have to list every user to receive this presence stanzas, and there can be many. 100 is not impossible depending on your roster, of course. And you need to keep track of a lot of things. Whenever a new chat is opened/closed you have to renew the XEP-0033 presence stanzas. I'm not fond of it. And if you are changing global presence all is lost.

Another way is to (manually ?) set global presence and add a status message to active chats that it is not for them. I don't know.

[Zbiggy (zb-ispid)]

"First sending a global presence change whenever you get a new chat, and then directed presence to each with whom your are actively chatting with can be a bit too annoying for them."

But there isn't any other possibility available. If it won't be automatic - still I'll have to do it "by hand", to let the others know, that I'm somewhat busy chatting.

But such way it will be annoying (first of all) to me. So, why not make it automatically?

[sander (s-devrieze)]

2007/11/23, Mats <email address hidden>:
> OK, I'm trying to digest your opinions here. You both agree that the present implementation is crap, so I perhaps can archive it for any future use by having it set config() 0.
> First sending a global presence change whenever you get a new chat, and then directed presence to each with whom your are actively chatting with can be a bit too annoying for them.
>
> If you think of XEP-0033 I don't think this actually solves it since you
> have to list every user to receive this presence stanzas, and there can
> be many. 100 is not impossible depending on your roster, of course. And
> you need to keep track of a lot of things.

As a non-coder, the logic doesn't seems to be too difficult to me. You
just need to make 2 things:
1) a function that monitors the internal "busyness" indicator and
which contacts are involved (already explained before how this should
work in detail).
2) a function that can send the "directed presence" (Busy+message) to
all online contacts *besides* the active contacts found by the first
function. For this, XEP-0033 will be used if supported/implemented.
Also this function will send this "directed presence" to contacts who
come online in the meantime.

So, the first function will do the hard work:
1) decide when the internal switch should be set to "busyness" and
when this should be disabled (this should be smart (*))
2) decide who are the involved contacts when the "busyness" internal
state is enabled
3) tell the second function to enable itself when the internal state
changed to "busyness", when enabled it will send the directed presence
and it will monitor to send this directed presence also to contacts
that come online in the meantime
4) tell the second function to disable itself when the internal state
changed to "busyness"

(*) The delays, times, numbers, and so forth can depend on; examples
of possible measures:
- the number value entered by the user in the preferences to define
the number of active chat sessions before the Auto-Busy should be
enabled
- the current global presence (if the user enabled "free to chat", we
can assume he is not busy with other stuff and is totally focused on
chatting, so the numbers, intervals etc all can be interpreted less
strict)
- the time when the presence was changed (if this was long ago, the
outcome maybe should be different)
- your imagination about what can be good measures to indicate when,
when not, and how long the "bussyness" internal state should be set.
You should keep the end user and his contacts in mind for this logic.

>Whenever a new chat is
> opened/closed you have to renew the XEP-0033 presence stanzas.

The logic should be smart: simply opening/closing chat windows should
not influence the logic. An active chat session, is a session in which
the user sent a message or received any stanza during the last <put a
good value here> seconds. So, the user may have 100 open chat windows
but still have only 2 "active chat sessions".

> I'm not
> fond of it. And if you are changing global presence all is lost.

If the user decides to manually change the presence during an internal
"busyness" state, this state should be reset and all p...

[Mats (matsben)]

Started implementing https://bugs.launchpad.net/coccinella/+bug/163749/comments/2
The logic is not so simple and there are a lot of conditions involved. Unfinished.
I use the usual global/directed presence stanzas to start with.

Using XEP-0033 is not without problems as I've said. It doesn't reduce so much traffic since you still have to send to all available minus the active chat contacts a stanza:

<address type='to' <email address hidden>/Work' desc='Joe Hildebrand'/>

It is shorter than full presence stanzas but still...
Using first global presence and then directed presence is typically much, much shorter, so the point with XEP-0033 is completely lost!

[Mats (matsben)]

There is now a working implementation that is close to https://bugs.launchpad.net/coccinella/+bug/163749/comments/2 with some exceptions:

> * the definition of an active chat session should change when the user sets a higher value in the preferences (e.g. when he sets 3 there should be activity each 30 secs for a session to be marked as active, ...

Objections:
1) If you have just enough of chat threads open that will generate auto busy and the "activity" of each thread varies, as it normally does, it is very easy too see that it can often happen that we jump from "auto busy" to "normal" depending on our own activities and others. Then other online contacts would see our presence junk back and forth between "available" (or whatever) and busy. Having a kind of time out as you suggest helps a bit to insert "friction" in the system so it wont jump that often, but it is still a problem.
2) Detecting "activity", our own and others, in each chat thread is a very complicated thing to keep track of timers set and fired. It can also be necessary to set and cancel a timer for each key stroke we do. This is just hopeless! Having a global polling timer would be simpler to do, but is considered bad programming habit.
3) I now only count open tabs as active which is much less likely to trigger that kind of busy/normal jumping. Besides, it is more intuitive for the user because that is exactly what the prefs settings are saying.

I have a kind of mechanism to revoke auto busy depending on settings and open tabs now that is complicated enough with several timers competing to fire. You have to see the code for the exact behavior: ::Chat::AutoBusy* (end of Chat.tcl).

Did some simple tests which worked OK.

[sander (s-devrieze)]

2007/11/25, Mats <email address hidden>:
> There is now a working implementation that is close to
> https://bugs.launchpad.net/coccinella/+bug/163749/comments/2 with some
> exceptions:

/me will test

> > * the definition of an active chat session should change when the user
> sets a higher value in the preferences (e.g. when he sets 3 there should
> be activity each 30 secs for a session to be marked as active, ...
>
> Objections:
> 1) If you have just enough of chat threads open that will generate auto busy and the "activity" of each thread varies, as it normally does, it is very easy too see that it can often happen that we jump from "auto busy" to "normal" depending on our own activities and others. Then other online contacts would see our presence junk back and forth between "available" (or whatever) and busy. Having a kind of time out as you suggest helps a bit to insert "friction" in the system so it wont jump that often, but it is still a problem.

Why will it still be a problem?

> 2) Detecting "activity", our own and others, in each chat thread is a very complicated thing to keep track of timers set and fired. It can also be necessary to set and cancel a timer for each key stroke we do. This is just hopeless!

No, it's just a challenge for you! ;-)

> Having a global polling timer would be simpler to do, but is considered bad programming habit.
> 3) I now only count open tabs as active which is much less likely to trigger that kind of busy/normal jumping. Besides, it is more intuitive for the user because that is exactly what the prefs settings are saying.

I see 3 issues with simply counting open tabs:
1) What if you opened a tab to simply look up some chat history of
this contact which you need to use in another conversation? This tab
will be no active chat.
2) What if people (like me) sometimes keep a chat tab open because
they know they will need to chat with this contact later that day? The
conversation may have been ended and a new conversation may start in
the same tab later that day. But currently there is no active chat
session in this tab.
3) What if a user keeps a few tabs always open between Coccinella
sessions because he/she needs to chat with these contacts quite often?
But currently there is no active chat session in this tab.

So, either you need to replace the current measure with another
measure (e.g. like my suggestions), or you need to add another measure
to the current measure.

--
Mvg, Sander Devrieze.

[sander (s-devrieze)]

Issues found after some tests:
* presence is not changed back to the previous presence when tabs are closed
* presence is send to all users; including those with whom you are chatting with

[Mats (matsben)]

On 11/25/07, sander <email address hidden> wrote:
> Issues found after some tests:
> * presence is not changed back to the previous presence when tabs are closed

There is a delay as you indicated in the tracker. In code:
proc ::Chat::AutoBusyTimer {} {
    variable autoBusy
    upvar ::Jabber::jprefs jprefs

    set deltaN [expr {$jprefs(aa,busy-chats-n) - $autoBusy(nChats)}]
    set ms [expr {60000/$deltaN}]
    set id [after $ms [namespace code AutoBusyTimerCB]]
    lappend autoBusy(pending) $id
}

> * presence is send to all users; including those with whom you are chatting
> with
>

That's what we discussed. I use global and directed presence stanzas, like:
    # Set global busy presence.
    set autoBusy(presSet) 1
    ::Jabber::SetStatus dnd -status $jprefs(aa,busy-chats-msg)

    # Set directed presence as it was before to active chat contacts.
    foreach chattoken [GetTokenList chat] {
 set jid [GetChatTokenValue $chattoken jid]
 ::Jabber::SetStatus $autoBusy(show) -status $autoBusy(status) -to $jid
    }

So chat contacts get two presence stanzas, as we discussed before.

[sander (s-devrieze)]

2007/11/25, Mats <email address hidden>:
> So chat contacts get two presence stanzas, as we discussed before.

Well, you know I'm not very fond of this "workaround" solution. Also,
it doesn't seem to work. All my contacts get the "directed presence".
They first get the busy presence and shortly thereafter the directed
presence which only should be received by the active people.

Either this is a bug or yet another bug in the Google Talk server. In
case of the latter it is maybe time to test all other bugs in the
Google Talk server again to see if they are already fixed and then
blog about the status of these bugs and about the new bug we found
(with link to previous blog post). At the end of the blog post you
then can write something like "We are sure the Googlers will fix the
mentioned bugs soon so that third-party software will work as good as
they do on XMPP compatible servers that do not suffer these protocol
compatibility bugs." <--you have a big audience so the Googlers will
read your request ;-)

--
Mvg, Sander Devrieze.

[Mats (matsben)]

First, I have now more closely implemented your ideas in https://bugs.launchpad.net/coccinella/+bug/163749/comments/2, and the active parts in particular. You are pushing me ;-) And the only reason I do it is the intellectual challenges which I cannot resist.
Anyway, activity on each open thread is detected using timers that are set only when something is being sent or received, thus no key press events etc. An activity event is when these things happen, and at the same time a timer is set to detect any inactivity as:

    # Set the "inactivity" time depending on prefs setting.
    set ms [expr {20000 * $jprefs(aa,busy-chats-n)}]
    set id [after $ms [namespace code [list AutoBusyInactiveEvent $chattoken]]]

In that case the thread is not active anymore. Both the active and inactive events generate a check to see if we are busy (then send auto-busy), or not busy anymore. In the latter case we set a timer again according to your proposal to remove auto-busy:

    set deltaN [expr {$jprefs(aa,busy-chats-n) - $autoBusy(nActive)}]
    set deltaN [max $deltaN 1]
    set ms [expr {60000/$deltaN}]

The number of open chat tabs are not taken into account anymore anywhere. Note that to remove an auto-busy state we must first wait for any inactivity, and then wait again

Second, when I set auto-busy the following presence stanzas are sent off:

SEND: <presence><status>testing auto busy...</status><show>dnd</show>...
SEND: <presence to='matben@localhost'>... (I was chatting with myself)
SEND: <presence to='killer@localhost/Psi'>...

When I set the limit to 1 active for busy and chat with myself, I get to the Psi client:

<presence from="matben@localhost/Coccinella@Mats-Bengtssons-dator" to="killer@localhost" >
<status>testing auto busy...</status>
<show>dnd</show>...

and nothing more. So it looks like another "oddity" of the gtalk server. Can you try to detect what xml is sent out from the coccinella and what xml is received by other clients. I don't have any way to debug this since I have only a single gmail account available.

[sander (s-devrieze)]

2007/11/26, Mats <email address hidden>:
> First, I have now more closely implemented your ideas in https://bugs.launchpad.net/coccinella/+bug/163749/comments/2, and the active parts in particular. You are pushing me ;-) And the only reason I do it is the intellectual challenges which I cannot resist.

heh

> The number of open chat tabs are not taken into account anymore
> anywhere. Note that to remove an auto-busy state we must first wait for
> any inactivity, and then wait again

Not good: most people can handle more than 1 active chat sessions
without being too busy to handle an additional chat session. Or do you
mean you now count the number of active sessions like in my request
(which is good)? B-)

> and nothing more. So it looks like another "oddity" of the gtalk server.
> Can you try to detect what xml is sent out from the coccinella and what
> xml is received by other clients. I don't have any way to debug this
> since I have only a single gmail account available.

I also have only a single gmail account. I don't think this is a
problem for testing; you can add a user on jabber.se etc to your
Google Talk roster...just invite <email address hidden> (or the way
around). You then get a subscription request in GMail (or vice versa).

/me has no time today for testing this :-(

--
Mvg, Sander Devrieze.

[Mats (matsben)]

On 11/26/07, sander <email address hidden> wrote:
> > The number of open chat tabs are not taken into account anymore
> > anywhere. Note that to remove an auto-busy state we must first wait for
> > any inactivity, and then wait again
>
> Not good: most people can handle more than 1 active chat sessions
> without being too busy to handle an additional chat session. Or do you
> mean you now count the number of active sessions like in my request
> (which is good)? B-)

Yes :-)
But you need to look into the settings I've made (time constants and
formulas) so they make
sense. There are lot of timers running (I warned you), each thread
normally has its own to
detect activity/inactivity, and then there is another set that revokes
aut-busy settings to "normal" again.
You need to see the code at Chat.tcl. They are all named
::Chat::AutoBusy* and is a self
contained part of Chat. Easy to read.

>
> > and nothing more. So it looks like another "oddity" of the gtalk server.
> > Can you try to detect what xml is sent out from the coccinella and what
> > xml is received by other clients. I don't have any way to debug this
> > since I have only a single gmail account available.
>
> I also have only a single gmail account. I don't think this is a
> problem for testing; you can add a user on jabber.se etc to your
> Google Talk roster...just invite <email address hidden> (or the way
> around). You then get a subscription request in GMail (or vice versa).
>

Yes, of course. I'm stupid!

/Mats

[Mats (matsben)]

Tested my gmail account together with two jabber.se accounts. Tested setting auto busy from gmail account, tested auto-busy from either jabber.se accounts, and all presence stanzas get directed where they should be. I cannot see any problems with this.

[Mats (matsben)]

Now added that closing a tab generates an inactivity on the chat thread right away without any delay from timers. This should make revoking auto-busy in these situations much faster since only one timer is involved for revoking the aut-busy state.

[Zbiggy (zb-ispid)]

I've got an idea for a little improvement: yes - now, when there are chat windows opened, if the amount reaches the setting, status is changed to "unavailable". But still someone can try to chat, "because it's important..." and so on. Perhaps could be possible, in such case, to insert automatically a response into newly opened chat window (and send it to caller), of the type, for example: "I'm very sorry - as you can see, I'm too busy at the moment to answer; if you can wait a little, I'll call you back ASAP, when I finish". Just the standard "hey, wait a moment..." response, which everyone can type in such situation. It could be even customizeable.

What do you think?

[sander (s-devrieze)]

Looks also nice, see Bug #173777. You may also be interested in Bug #173779

[Zbiggy (zb-ispid)]

Yes, as I can see, it's not just me, who sees the problem. But my proposal is, as I think, a "kind solution". The caller has the answer, that "he has been noticed" - and simultaneously has been informed, that there can be delay in ev. chat. If he really wants it - he can wait then.

You know: during text chat messages, when the party cannot see you, no answer in such case - just changing the status from "chat" to "message" - can be misunderstood as a "harsh attitude".

[Mats (matsben)]

> if the amount reaches the setting, status is changed to "unavailable".

But it will only reach dnd (busy).
Right now you can add a status message to the auto-busy. Isn't that doing what you want?

In any case I have feature freeze for 0.96.4 since the translators must be given an opportunity.

[Zbiggy (zb-ispid)]

"But it will only reach dnd (busy)."

Whatever... the one with "no entry allowed" sign. ;)

"Right now you can add a status message to the auto-busy. Isn't that doing what you want?"

Not quite - I meant the case, when someone's trying to open new chat despite of the dnd status (and even ev. status message, advising against that).

"In any case I have feature freeze for 0.96.4 since the translators must be given an opportunity."

OK, there's no hurry.

[sander (s-devrieze)]

> OK, there's no hurry.

Also, it's maybe better to continue this discussion in the new bug
entries I opened...