Am 16.07.2009 um 09:39 schrieb Pedro Melo:
You write "solve the presence flood" and to me that reads as there is a big problem with it. Maybe that problem is obvious to you, but it really doesn't seem a problem to me. Can youelaborate exactly what is the problem with presence flood?
Well, basically, it's two problems: The spam of popups when you log in and the delayed presence.
I know that having it in the roster (bad idea, I already corrected myself - a new XEP which sends all initial presences in one stanza would make more sense) doesn't fix this. But this would force server developers to cache presences.
The real problem with the presence flood is that they come for about 5 minutes for me. It's like there's one wave of available presences every 30 seconds. This is kind of annoying if you just connect to see if somebody is online and don't know "Hm, is that person offline or haven't I just received the presence yet?"
I know that this is also an implementation issue, maybe more of an implementation issue than a protocol issue. But having a protocol that sends all initial presences at once would do two things:
1.) Force server developers to cache.2.) You know when you got all presences and then definitely know if somebody is online without waiting 10 minutes just in case you didn't get the initial presence yet.
The "initial-vs-other presence" problem (for end-user notification) is solved by the jabber:x:delay namespace. What other problems are there?
See above.
Is there a solution that will provide the same level of information (show, status, availability, priority and caps) that the current presence flood provides? And that works in a distributed environment?
It would basically be one stanza that includes all the presences. It could even keep the presences 1:1.
I would like to help and solve this problems with presence flood, but sincerely, I still don't see what they are.
-- Jonathan
PGP.sig
Description: Signierter Teil der Nachricht
