Oops... I should read the thread more carefully before posting. My
question was already addressed.
Sorry.
On Dec 15, 2008, at 4:29 PM, Robert Quattlebaum wrote:
On Dec 2, 2008, at 1:02 PM, Jack Erwin wrote:
Dirk Meyer wrote:
First of all, we need some sort of negative priority for bots.
On Dec 2, 2008, at 1:02 PM, Jack Erwin wrote:
Dirk Meyer wrote:
First of all, we need some sort of negative priority for bots. IMHO
it
maes no sense to send a message to a device that can not answer.
Blocking inbound messages with privacy lists can give you this
behavior.
Doesn't doing t
Having worked for quite some time in analyzing and designing user
experience for presence and IM systems (via SIP) that are user based
rather than device based, I find the message Mining solution a very good
tool for XMPP IM systems in order to accomplish this user based
experience. Providing com
Am 02.12.2008 um 22:58 schrieb Peter Saint-Andre:
Right, and that gets back to the definition of threads and chat
sessions, which we've never settled. Oddly, people seem to adjust
quite
well to the messy reality of not having neat definitions...
When I find the time, I'll try to provide a d
2008/12/3 Dave Cridland <[EMAIL PROTECTED]>:
>
> So... My desktop gets a message:
>
> to='[EMAIL PROTECTED]/desktop-client'>
>You still there?
>
>
> But, sadly, I'm not there - I've walked into the ktchen to boil the kettle.
> Luckily, I do have my mobile device upon me. My desktop clien
On Wed Dec 3 10:20:12 2008, Dirk Meyer wrote:
Dave Cridland wrote:
> But, as well as that, it also does this:
>
>
>
>
>
>
>
If I'm in your roster, don't I get the presence update, too?
No, this is directed presence, not a broadcast - note the to
attribute - so it'l
Dave Cridland wrote:
> But, as well as that, it also does this:
>
>
>
>
>
>
>
If I'm in your roster, don't I get the presence update, too? And I would
think: Ah, he is chatting with Peter again. Not good for privacy. Maybe
I always wanted to know the JID of th
Thanks for the explanation. Grokkage in progress. Questions shall follow.
> On Tue Dec 2 19:10:12 2008, Peter Saint-Andre wrote:
>> Dave Cridland wrote:
>>
>> > I'm wondering if we can split the issue, here, and instead have
>> two
>> > mini-protocols:
>> >
>> > 1) The "Hey, I have pending messag
On Tue Dec 2 19:10:12 2008, Peter Saint-Andre wrote:
Dave Cridland wrote:
> I'm wondering if we can split the issue, here, and instead have
two
> mini-protocols:
>
> 1) The "Hey, I have pending messages here!" one. (ie, a
bare_jid-wide
> version of the flashing taskbar item thingy.)
>
> I
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
Jonathan Schleifer wrote:
> Am 02.12.2008 um 22:24 schrieb Peter Saint-Andre:
>
>> I think that XEP-0085 is fine as a hint to unlock and send to
>> the bare JID again.
>
> I think we should get that confusion and mess about session termination
> vs. fixed first.
Right, and that gets back to th
On Tue, Dec 2, 2008 at 9:34 PM, Matthew A. Miller
<[EMAIL PROTECTED]> 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 g
Am 02.12.2008 um 22:24 schrieb Peter Saint-Andre:
I think that XEP-0085 is fine as a hint to unlock and send to
the bare JID again.
I think we should get that confusion and mess about session
termination vs. fixed first.
--
Jonathan
PGP.sig
Description: This is a digitally signed mess
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
now idle client continues to receive a conver
Jonathan Schleifer wrote:
> Am 02.12.2008 um 21:55 schrieb Joe Hildebrand:
>
>> 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
>
Jonathan Schleifer wrote:
Am 02.12.2008 um 22:02 schrieb Jack Erwin:
Blocking inbound messages with privacy lists can give you this behavior.
Not a good idea, as they would be silently dropped and no error returned.
Fair enough. This is not an issue with the current spec, though:
The rec
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 t
Am 02.12.2008 um 22:02 schrieb Jack Erwin:
Blocking inbound messages with privacy lists can give you this
behavior.
Not a good idea, as they would be silently dropped and no error
returned.
--
Jonathan
PGP.sig
Description: This is a digitally signed message part
Am 02.12.2008 um 21:55 schrieb Joe Hildebrand:
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.
Maybe we want t
Dirk Meyer wrote:
First of all, we need some sort of negative priority for bots. IMHO it
maes no sense to send a message to a device that can not answer.
Blocking inbound messages with privacy lists can give you this behavior.
My laptop receives the message and tries to notify me. After a use
On Dec 2, 2008, at 12:40 PM, Kevin Smith wrote:
On Tue, Dec 2, 2008 at 7:25 PM, Jonathan Schleifer
<[EMAIL PROTECTED]> wrote:
I wouldn't want that, I really wouldn't want that. I have an mcabber
That's ok - when it's not the only online resource, mcabber will know
(through mine-ing) that it'
Am 02.12.2008 um 20:37 schrieb Matthew A. Miller:
I assert that message mine-ing would actually solve your problem
better than presence priorities.
How? IMO, that works perfectly. I don't have to do anything manually.
The message usually just goes where I am, thanks to automatically
adju
Peter Saint-Andre wrote:
>> ejabberd already does this if there is more than one resource with the
>> highest prio. If you have for example two resources with prio 50 and one
>> with prio 30, both with prio 50 will receive messages to the bare JID.
>
> Most servers do that. What I'm suggesting is m
On Tue, Dec 2, 2008 at 7:25 PM, Jonathan Schleifer
<[EMAIL PROTECTED]> wrote:
> I wouldn't want that, I really wouldn't want that. I have an mcabber
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 t
On Dec 2, 2008, at 12:25, Jonathan Schleifer wrote:
I wouldn't want that, I really wouldn't want that. I have an mcabber
connected all the time on my router with priority 0. It's rarely
used and never used when any other client is connected. When
connecting from any of my other machines, th
> I wouldn't want that, I really wouldn't want that
Presence-based routing has always been a usability nightmare, and
Googles' implementation improves upon that quite a bit. However, it's
not perfect, hence the message mine-ing, which would probably solve
your (very advanced) use case.
cheers,
Re
Am 02.12.2008 um 20:14 schrieb Peter Saint-Andre:
Most servers do that. What I'm suggesting is more of the Google Talk
behavior -- a message sent to the bare JID gets sent to *all*
resources
regardless of priority. That is, priority is ignored and maybe even
deprecated.
I wouldn't want that
Jonathan Schleifer wrote:
> Am 02.12.2008 um 20:10 schrieb Peter Saint-Andre:
>
>> (just make it so that they send bare-JID message to all resources)
>
>
> ejabberd already does this if there is more than one resource with the
> highest prio. If you have for example two resources with prio 50 an
Am 02.12.2008 um 20:10 schrieb Peter Saint-Andre:
(just make it so that they send bare-JID message to all resources)
ejabberd already does this if there is more than one resource with the
highest prio. If you have for example two resources with prio 50 and
one with prio 30, both with prio
Matthew A. Miller wrote:
> I think that message mine-ing is a very elegant and simple solution to
> determining user intent. Priority provides a course view of the user's
> attentiveness and gets us mostly there, but requires users to be
> proactive (e.g. diligently changing their presence).
In f
Dave Cridland wrote:
> I'm wondering if we can split the issue, here, and instead have two
> mini-protocols:
>
> 1) The "Hey, I have pending messages here!" one. (ie, a bare_jid-wide
> version of the flashing taskbar item thingy.)
>
> I'm wondering if intra-jid presence can be made to do the fir
I think that message mine-ing is a very elegant and simple solution to
determining user intent. Priority provides a course view of the
user's attentiveness and gets us mostly there, but requires users to
be proactive (e.g. diligently changing their presence). On the other
hand, message mi
On Mon Dec 1 18:45:43 2008, Dirk Meyer wrote:
I like the idea, but what happens if I switch clients during a
conversation? In your example, we chat with the desktop client. I
think
we are done, but do not close the chat window (I sometimes do that).
(I always do... I leave chat windows open
> As a user I know and love the behaviour of Gajim: priority depends on
> the status (it's only high for available or chat and low for
> away/dnd/xa). Combined with the auto-away feature that many other
> clients have too will make messages go to the right resource without any
> intervention.
This
Two things:
1) When you switch clients, there should be a presence change. On any
presence change, the sender should unlock from the current resource,
and send to the bare JID again.
2) When I switch devices, I'd like to get at least the messages I
haven't seen from the old device to the ne
Stephan Maka wrote:
As a user I know and love the behaviour of Gajim: priority depends on
the status (it's only high for available or chat and low for
away/dnd/xa). Combined with the auto-away feature that many other
clients have too will make messages go to the right resource without any
interve
Hi,
Jack Erwin wrote:
> Message mine'ing provides more of a "do what I mean" experience for
> the end user. When he leaves his desk, he will still be alerted via
> his mobile client when a new conversation has been initiated, and will
> do it without any sort of preparatory action. If the end u
Jack Erwin wrote:
> Current practices involve some sort of manual intervention. For example,
> the end user must manually set his priority, or provide some sort of "focus"
> to the newly active client application to allow for automatic priority
> brokering. Expecting an end user to remember t
Hello. My name is Jack Erwin, and I am the server architect at
WebEx/Jabber. Joe Hildebrand and St. Peter have asked me to post my
thoughts on the message mine'ing XEP that has recently been proposed, so
here goes:
The problem that we are trying to solve here is one of priority
management
39 matches
Mail list logo
