[Standards] Message Mine'ing

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


On Tue, Dec 2, 2008 at 9:34 PM, Matthew A. Miller
<linuxwolf at outer-planes.net> wrote:
>> 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
> (-:

Right, that's what I don't see yet - could someone explain it to me in
really short words, please?

So everyone can understand my misunderstanding:

Mineing solves most things fine, apart from the one issue of when
something should be un-mined.
I had thought that what was being suggested was that when a user
leaves one machine to go to another, he should hit a button on the
machine labeled "release Mines", which could either change presence,
or send <gone/> or any number of other notifications. Roughly
equivalent to this is that when the user reaches the new machine, he
can do some Remote Controlled "release Mines" on the other client. If
this was the case (and I'm assuming it's not, and hoping someone will
explain to me where I went wrong), then the user could just as easily
hit the "lower my priority" button (either locally or remotely) as the
"release Mines" button, which would in turn leave the new client with
a higher priority and therefore get stuff routed to it without a Mine.

Clearly some part of the puzzle has passed me by - I'm not trying to
be belligerent, I'm just missing that piece.

> 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.

Great then.

/K



More information about the Standards mailing list