Presence problem in large MUC rooms.

Goffi <[email protected]>
Newsgroups gmane.network.jabber.standards-jig
Message-ID <4708877.LvFx2qVVIh@tazar3>
Hi,

Following what I've said yesterday at the summit, I would like to explain more 
my idea, and get your feedback.

So basically the problem with presence in large MUC is that we get 2 things:
- initial presence when we join the room
- all the presence update when people join and leave, which is quite often 
with people on mobiles.

So my point was that we are seeing MUC by the way it's used today. But we 
don't have to.

We don't have to be actively in the room. What we want when we are in a large 
room, is to be able to check it when we want, and be notified when we are 
mentioned.

For smaller rooms, we may want to be notified on each new message.

The way I see it, we could have 2 ways to join a MUC: active and passive.

The active join would be what we do today, we get all the presence, and 
updates, it's really bandwidth intensive.

The passive join, on the other hand, would only say "we are in the room". The 
MUC service would then notify the client only in case of mention (or for any 
message in case of "subscribed" room).

Benefit:
- we don't have presence spam anymore, the client does an active join only 
when the user want to actually be in the room. So it's only one room at the 
time.
- client doesn't have to actively parse message to look for mention, on mobile 
it will get a push notification and wake up only when necessary
- It should be easy to implement on top on existing MUC implementation
- It's backward compatible: non-compatible client will just to "active" join 
all the time, and get all the presence spam.

Probably we can also optimize the initial presence in case of active join, but 
that's another topic.

I think that solves the presence issue. Let me know what you think about it.

Best,
Goffi

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 488 B)
-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEsNZvWyEnjW9SVudbKqmcu6xuKwwFAml8fqgACgkQKqmcu6xu
KwzU1QgAupJIwTnY36zcil3WxdHwvhRAIxuWi5sI0y8unUt6rkQ+F4BWxC3YQGOI
adTdSc92+2UBaDy6mIpTCeIikwJSSzxHI9wymueY5erqjFRzwl7gnrJWpldzQ/7/
a9ev6eMt3r/4NgP3OysG0qH63J6PTwAh0kZZRX0m8tK16p4Y5e6CgBwrctBbc3hW
mDkr3G/QPpsbOvnKwA1C9qUBehOajMIOwIVSraW5/YJwDaZZzeEQCcxS5Z5s4nPh
bXFfE0CI1rmbIFpW6sdmyQdjAXrdL3ZCe9NL1f9epG2LDKttGJPC4rhWTmtdqJon
I3oFtKc74r+tAOM63TjHSDCJt7onkQ==
=sqf8
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.