On Tue, Dec 2, 2008 at 8:55 PM, Joe Hildebrand <[EMAIL PROTECTED]> wrote: >> 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.
That's what I said ;) >> 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. It's not that I mind changing presence - what I wonder, though, is that if some user interaction is required, couldn't the user set their priority instead? I wonder how far that would get us. >> 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. As long as it is possible to sanely represent the protocol in the client, I'm happy - it would become a protocol issue if there was no reasonable way to present it to the user, I think. /K
