[Standards-JIG] proto-JEP: Smart Presence Distribution
Carlo v. Loesch
CvL at mail.symlynX.com
Tue May 30 09:58:07 UTC 2006
| Mridul wrote:
| > The implicit creation of a list could go out of sync very fast , does
| > not take care of updates to privacy profiles and looks very 'hackish' imo.
| > Why not make it explicit ?
You are talking about the first proto-JEP, not the current one I'm afraid.
We have indeed gone through these aspects before and have rewritten the
JEP to use the outgoing presence information rather than the rosters, so
according to the current proto-JEP, privacy profiles are fully supported.
| > The initiating server can request for a list creation with a set of bare
| > jid's and then use that as 'to' in subsequent presence stanza's -
Yes, this is how the context lists operate.
| > similar in ways to muc I guess.
MUC doesn't do that yet, but our pre-proto-JEP on "smartchat" suggests
Richard Dobson typeth:
| This was my original suggestion, but they seem to be very against it for
| some reason, they have still yet to really explain why.
Your idea was to combine JEP-0033 syntax with our idea of keeping state
in form of context lists on the recipient side. That is a possible way
to go about it, but it is redundant with the way presence is to be sent
out according to RFC 3921. If you're going to make a completely new
distribution scheme for presence, you are either being redundant, or
disabling large parts of RFC 3921 in your interserver communications.
Our new proto-JEP makes use of the presence distribution according to
RFC 3921 and only delicately extends this to re-use the information and
save on bandwidth. I am sorry you didn't notice there is fundamental
difference from our earlier proto-JEP to the current one. I think it
has even doubled in size. :-)
| > Either we can expose ways to add/delete jid's to this list , or just
| > recreate a new list depending on what gets decided here.
Yes that's what we have. Look at the List Use Cases in 5.2 of
| > If the receiving server sends an error about list unavailability ,
| > initiating server can recreate the list again.
Correct, see 5.2.4.
| > If some of these lists are constant/static , these lists could be reused
| > for different users as an optimization - need not be specific to a user.
| > (Like an admin group , etc) - just a thought , we need not get into this :-)
| Yes exactly.
That's a possible extension for completely different purposes than Presence
or MUC. Yes, the lists could undoubtedly be extended in such a way, if a
good JEP takes care of all the necessary steps.
| > Just to add , if this gets supported , it will need to be a stream
| > feature I think ... not specific to a user/group/etc.
| It would be a disco feature, rather than a stream feature.
We have gone through that and opted for disco.
| > We could extend this to other 'needs' also.
Yes, we have even looked at how Pubsub can work with context lists
on the receiving server side. It's not easy because it would need to
define many lists for each combination of user settings, like digest
vs no-digest etc. etc.
| don't worry, yes ive already suggested this, even though they seem to be
| ignoring it, more fuel on the fire, good to hear minds are thinking alike :)
No Richard, we have gone through all the suggestions we got, taken them
seriously, and come up with an in large parts new solution, so please come
and take a look at it.
» Carlo v. Loesch » http://symlynX.com » psyc://ve.symlynX.com/~lynX
xmpp:lynX at ve.symlynX.com » irc://ve.symlynX.com/#symlynX
CryptoChat » https://ve.symlynX.com:34443/LynX/?room=symlynX
More information about the Standards