Re: [Standards] Message Mine'ing

[Matthew A. Miller]

On Dec 2, 2008, at 14:10, Kevin Smith wrote:

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

that you must go Away (or similar) when leaving your machine, and if
we did that we may as well stick with priorities.)

now idle client continues to receive a conversation unless we mandate

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.

Presence priority gets us mostly there if the user is proactive. Mine- ing gets us more there if the user is reactive. Human beings are already wired to be reactive, and mine-ing exploits that (-: NOTE: I am not suggesting we do away with presence priority. I think there's still value there as a rough passive indicator to a user's attentiveness.

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?

issue, not a protocol issue.

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

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.

Within the first 60 minutes of reading this spec, there were about half a dozen ways I could see to implement this in the clients I work on regularly. Some prototyping has shown that the protocol's got what I need (so far), it's just a usability/implementation issue to resolve.

/K

--
Matthew A. Miller
[EMAIL PROTECTED]

smime.p7s
Description: S/MIME cryptographic signature