[Standards] Message Mine'ing

Matthew A. Miller linuxwolf at outer-planes.net
Tue Dec 2 23:01:53 UTC 2008

On Dec 2, 2008, at 14:50, Kevin Smith wrote:
> 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.

Ok, this is the "I leave chat windows open forever" scenario. I was  
concentrating on the (arguably more common) "I leave chat windows open  
for a little while" scenario[1].  Hopefully, the following words  
aren't too long (-:

For "your" scenario, I don't know if there's a way to avoid the user  
doing something to change state (locally or remotely), or clients  
being aggressive on their recipient address resets (e.g. fairly short  
timeouts, which I don't think are as wrong and/or evil as others).

For "my" scenario, mine-ing gets closer to the ideal than presence/ 
priority changes.  This is even more true when client's use the <gone/ 
 > chat state (which I'm seeing more and more frequently).

I hope this helps, at least explain my enthusiasm (-:

Matthew A. Miller
linuxwolf at outer-planes.net

[1] I argue it is more common because that's the behavior I see with  
most of my colleagues, customers, family, and friends.  If I didn't  
work for an organization that lives and breathes this, I wouldn't try  
to argue the point too vigorously (-:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2238 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20081202/ac3ab4f1/attachment.bin>

More information about the Standards mailing list