[Standards] Message Mine'ing

Kevin Smith kevin at kismith.co.uk
Tue Dec 2 21:10:05 UTC 2008

On Tue, Dec 2, 2008 at 8:55 PM, Joe Hildebrand <hildjj at gmail.com> 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.


More information about the Standards mailing list