On Dec 2, 2008, at 12:40 PM, Kevin Smith wrote:
On Tue, Dec 2, 2008 at 7:25 PM, Jonathan Schleifer
<[EMAIL PROTECTED]> wrote:
I wouldn't want that, I really wouldn't want that. I have an mcabber
That's ok - when it's not the only online resource, mcabber will know
(through mine-ing) that it's not being talked to, so there's no reason
for it to be logging the messages.
I would suggest that it could remove them from the log when another
client Mine's them, if that's the behavior you're after.
Now I understand it a bit better, I think it probably does solve the
problem it's setting out to solve, mostly (although it can't help in
the case where someone leaves one machine to go to another, and the
now idle client continues to receive a conversation unless we mandate
that you must go Away (or similar) when leaving your machine, and if
we did that we may as well stick with priorities.)
Hopefully, adding the XEP-146 interaction section will make this more
clear. If we think this important to do without changing presence, we
can either reuse XEP-85 "gone", or add a new state of "moved" that is
an unlock hint.
What's not clear to me is how a client knows that it's the active
client in order to Mine the message - should it be displayed to the
user on all clients, and then withdrawn from view after it's been
Mined elsewhere (Client UI question), with a client only mineing it
when the user is known to have read it somehow?
That was the intent. The "known to have read it somehow" bit has some
suggestions in the implementation notes. I look at that as mostly a
UI issue, not a protocol issue.
--
Joe Hildebrand
