Hi,
On Feb 28, 2009, at 10:18 AM, Waqas Hussain wrote:
On Thu, Feb 26, 2009 at 9:32 AM, Pedro Melo <[email protected]>
wrote:
On Feb 25, 2009, at 7:36 PM, Pavel Simerda wrote:
On Tue, 24 Feb 2009 15:54:38 +0000
Pedro Melo <[email protected]> wrote:
Hi,
On Feb 24, 2009, at 12:49 AM, Pavel Simerda wrote:
There are several cases when subscription databases in XMPP are
inconsistent.
You may view subscription information as a global distributed
database.
Subscription state between two JIDs, for example a...@a and b...@b are
stored
in two places at the same time. Servers A and B maintain their own
copies of subscription state.
[....]
What with the roster items that are inconsistent?
* Mark as inconsistent, let the client present it to the user to
take action.
* Auto-repair and thus maintain consistency
Looking forward to all feedback.
When you send out a <presence type="probe" /> include the local
"view" of the subscription state.
Btw presence probe seems too weak... as it doesn't reveal full
subscription state.
that's what I'm saying: include the full subscription state in the
presence
probe so that the other side can detect mis-matches.
Best regards,
I'm considering doing this in Prosody:
<presence type="probe" from="[email protected]"
to="[email protected]"><item subscription="both"/></presence>
Don't know if you should also include the ask-out/ask-in flag. Also
original request <status>.
I would, but I admit not having done some serious thinking on the
implications. It *seems* ok.
What action is appropriate is open for debate. What should the
resulting state be? The lowest common permissions (possibly sending
unsubscribe[d] to the contact or changing the user's subscription for
contact)? The highest common permissions (possibly sending a
subscrive[d] to the contact and changing the user's subscription for
the contact)?
Highest common permissions, maybe. I've started a table below for some
cases, and I have some doubts. Should we upgrade the Receiver
subscription to a better state? For example: if you have a To
subscription to me and I have a None to you, should I be upgraded to a
From? Not sure yet. It can be used for presence spam. A more careful
approach would send a unsubscribe.
And we need to look this in the other direction. If the Receiver is
'To' or 'Both' and the other side is 'None' or 'To', should we send a
'subscribed'? It makes sense for the Receiver, but from the POV of the
Sender, you are modifying my own subscription status, upgrading it.
I wrote the following table of what I think are the most safe
transactions: none of the subscriptions are "upgraded" in any way.
(note: for each "Recv resets to 'X'" it is implied that a roster push
would be sent to all connected resources)
Sender: none
Recv: to
=> Recv resets to 'none'
Sender: none
Recv: from
=> Recv resets to 'none'
Sender: none
Recv: Both
=> Recv resets to 'none'
Sender: To
Recv: none
=> Recv sends 'unsubscribe'
Sender: To
Recv: To
=> Recv resets to 'none', sends 'unsubscribe'
Sender: To
Recv: Both
=> Recv resets to 'From'
Sender: From
Recv: none
=> Recv sends 'unsubscribed'
Sender: From
Recv: From
=> Recv resets to 'none', sends 'unsubscribed'
Sender: From
Recv: Both
=> Recv resets to 'To'
Sender: Both
Recv: none
=> Recv sends 'unsubscribe' and 'unsubscribed'
Sender: From
Recv: From
=> Recv resets to 'none', sends 'unsubscribed'
Sender: From
Recv: Both
=> Recv resets to 'To'
From an IM user's point of view, trying to settle on the highest
common permissions seems more appropriate (and less confusing).
Well, the fact that we have asymmetrical states is a source of some
confusion. If you want to eliminate that, then you should have 'none'
and 'both' only.
But asymmetrical presences are very useful on some IM scenarios, like
transports.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [email protected]
Use XMPP!
