[Standards-JIG] proto-JEP: Smart Presence Distribution

Carlo v. Loesch CvL at mail.symlynX.com
Tue May 30 11:15:39 UTC 2006


Mridul typeth:
| Maybe I did not explain it properly enough - I am referring to
| "http://www.jabber.org/jeps/inbox/smartpresence.html".
| I was referring to the way the JEP is using outgoing presence info to
| cobble together a list on the fly in section 5.

The term "cobble" implies that the process is not well defined, but it is.

| It is making assumptions as to who all are in my roster based on the
| behavior of who all I send my presence updates to , or want the info to
| be sent to.

Incorrect. It remembers who you have sent presence to and whom you will again
later. If you change the privacy list, the change will propagate to all
involved servers.

| This IMO is not very desirable and can break at quite a lot of cases.

No. Name one.

| Using rosters was totally broken IMO - good to see that the JEP authors
| have moved away from that approach !

Not because the approach was broken, but because in Jabber rosters
operate in a way that cannot be trusted upon. That's okay, every
chat system has its culture, and we made a wrong presumption on
the safety of rosters in Jabber. No problem. We sat down and came
up with a different solution.

| >| > 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.
| 
| Exactly , why not use this ?
| Create a new list on the fly on the remote server with the required
| barejid's, and use that list as recipient to send presence updates to.

Yes. That's what happens, although it's a bit more deterministic than
"on the fly."

| The new list would take care of fanning out the updates to its local users.
| The traffic improvements would still be significant considering that the
| extra overhead is :
| a) list creation.
| b) list-recreation in case it has gone out of scope.
| I dont think this is entailing the security issues discussed with the
| roster approach , or the guesswork that the current approach is
| attempting on.

Correct, that's why our current proto-JEP is pretty good.
Thank you.  :)

| Ofcourse , not pushing for this :-) I am sure there might be other
| better ideas ... just an alternative to what is being proposed.

No, you are describing exactly what the proto-JEP does.

| >MUC doesn't do that yet, but our pre-proto-JEP on "smartchat" suggests
| >just that.
| 
| What I was referring to was the fact that - you send a message to the
| 'room' , all resources in the room (that is users) get this message :
| same concept is used for lists and what we are talking about here I guess.

It has been discussed on this list in February, that both groupchat and
presence are a one-to-many operation. It has also been discussed on IMPP
in 1999. Unfortunately XMPP has taken zero provisions for one-to-many
addressing and routing, that's why we're working out something now.

In PSYC we have already implemented both presence and groupchat using
the same multicast contexts, same algorithms and data structures.
We noticed how we just can't solve it as elegantly in our XMPP
implementation and would like to lay the fundaments to do that.

| I do not see how there are significant savings when comparing what
| Richard proposed to what is currently proposed in the proto-JEP ...

Both suggestions are using the same concept of context lists on the
receiving side, so they are both fundamentally right. Richards plan
however makes Presence as it is defined in XMPP IM 5.x useless,
whereas we keep on using it. It's a question of taste, I personally
don't mind rewriting the XMPP RFCs, but it is certainly out of the
scope of a new JEP then.

| Other than a 'to' being added to the presence stanza for a random list
| (and potential list recreation if what I mention above is implemented) ,
| the 'cost' is the same.

We were asked to re-introduce the 'to' in respect to the XMPP RFCs.
Our original suggestion was to leave it out, just as is being done
in the client to server protocol when sending <presence/>

| Without the guesswork , security issues, etc.
| There is no need to be different just to be "new" :-)

What guesswork? What security issue? And who's trying to be new and different?

| If it makes sense , we should consider - but as much as possible , it
| makes sense to integrate with existing proposals and protocols : they
| are already in use and will be easier to implement and extend for all
| concerned.

Exactly, that's what our proto-JEP does and Richard's proposal doesn't.

| This reuse is not proper reuse - it is introducing guesswork into the
| whole 'construction of the initial list' process.

You seem to enjoy wild assumptions, but you are wrong.

| Saw that , I was just commenting w.r.t what I was thinking about : I did
| notice that the proto-JEP mentions similar stuff :-)

It defines operations, not similar stuff.

| Exactly - it would become a generic : create "random lists" sort of thing.
| How you use these lists would be implementation dependent.
| Could be for MUC , for presence broadcast , etc ... not necessarily for
| multicast.
| The "life" of a list is also not gaurenteed - except for reasonable
| limits like atleast one operation on the list , prevent abuse by
| throttling number of lists being created , etc.
| 
| But then I think something like this is already in place right ?

You are thinking all along our lines. Just because we use the *existing*
syntaxes to populate certain lists that serve a certain purpose doesn't
mean you can't use those lists in a different way, populating them with
the appropriate protocol to that purpose. The data structures and
algorithms are there. You think a one-protocol-fits-all approach would
be nicer - alright, but then you have to do it against the current RFCs.

| Keep up the effort !

Thanks, Mridul.

I could use a virtual beer now.




More information about the Standards mailing list