[Standards] Message Mine'ing
hildjj at gmail.com
Tue Dec 2 20:55:22 UTC 2008
On Dec 2, 2008, at 12:40 PM, Kevin Smith wrote:
> On Tue, Dec 2, 2008 at 7:25 PM, Jonathan Schleifer
> <js-xmpp-standards at webkeks.org> 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.
More information about the Standards