On Thu, 12 Aug 2004 01:55:59 -0500, Nolan Eakins <[EMAIL PROTECTED]> wrote: > Reading this I came up with another possible solution. Your definition of > presence as availability at a specific time helped. It would be possible to > periodically send presence stanzas which would solve the problem, but doing > that may end up flooding the network. Doing that would be a bad idea, but > presence stanzas could specify when the presence will be updated again.
This doesn't get around the problem of having to deal with state for presence stanzas. This is a problem that I didn't fully realize until I had to work on a server :) What you are proposing isn't new.. checkout the SIMPLE RFC's. They have no such thing as long lived presence subscriptions and require entities to continuously subscribe. You are proposing the same thing except for regular availability stranzas. If we do this, it still requires routers to cache all of the presence packets that pass thru it, and "do the right thing" if they don't get another packet. It's these types of complications that make a protocol a lot more resource intensive and time consuming to implement. I really have to wonder if the added complexity of these types of protocol bits are really worth the gain of handling these somewhat "extreme" edge case scenarios. I do agree that we see these problems more and more because of s2s issues. I'd argue that the issue is that various s2s implementations are not as reliable and robust as they should be. It's not so much a deficiency in the protocols as it is a deficiency in the implementations. I know this to be true based on how often I (as a j.org admin) have to restart our s2s process because it becomes "borked" in a variety of ways. Perhaps the time we're spending on this discussion could go to improving the jabberd 1.4.3 s2s process and we'd all be much happier :) pgm. _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
