On Dec 15, 2008, at 7:03 PM, Justin Karneges wrote:
On Monday 15 December 2008 15:08:00 Robert Quattlebaum wrote:
Presence probes are useful to force a refresh of your presence state
if you were previously ignoring presence (say, via a privacy list
which blocks incoming presence).
It should really be the server's job to handle this problem. As
soon as you
stop ignoring some presence, a well-designed server should
automatically get
you that presence.
Is this behavior that you are describing defined anywhere? This sounds
like completely new behavior. It also sounds like it would be
significantly more work to implement than what I am describing,
considering how complex privacy lists are.
Today, you generally need to probe contacts that you unblock. It's
nice that
this works (as opposed to being SOL), but in my opinion it's a total
hack.
Sending a bunch of probes, one for each subscription, sounds like a
hack.
Sending a single probe and letting the server forward that to who you
are subscribed to sounds like reasonable behavior, IMHO.
It seems like we already have the vocabulary for the client to express
its needs to the server, we just need the server to know what to do.
To do that we need for everyone to generally agree on what should be
the correct behavior of the server when it receives an unaddressed
presence probe.
Blocking incoming presence is useful in mobile environments when
interest in other's presence is only necessary in very limited
contexts. Receiving and handling presence stanzas when they aren't
being used wastes power, so it is a good idea to not have them be
sent
at all. The problem then comes what do you do when you want to
actually view presence in a roster?
Turning off the privacy list and sending a single presence probe
makes
the most sense, but handling unaddressed presence probes are
currently
not widely supported.
In a perfect world, you'd just turn off the privacy list and be
done. But, in
an imperfect one you have to probe all of your contacts. That, or try
rebroadcasting your own presence, which in turn may cause some
servers to
reprobe.
Rebroadcasting the client's presence doesn't really do what we want in
this case.
I agree there's a problem that needs to be made better. Let's just
do it the
right way then.
The trick is that if we are going to change the behavior, we need it
to be simple enough that server implementors will actually consider
implementing it.
__________________
Robert Quattlebaum
Jabber: da...@deepdarc.com
eMail: da...@deepdarc.com
www: http://www.deepdarc.com/
