[jdev] last presence confusion

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Fri Jan 25 13:43:33 CST 2008

On Friday 25 January 2008 11:09 am, Peter Saint-Andre wrote:
> Maciek Niedzielski wrote:
> > Peter Saint-Andre wrote:
> >> Maciek Niedzielski wrote:
> >>> On Sat, Dec 22, 2007 at 12:23:38PM -0800, Justin Karneges wrote:
> >>>> On Thursday 20 December 2007 2:52 pm, Peter Saint-Andre wrote:
> >>>>> So a nice server will return the last unavailable presence
> >>>>> information (with a Delayed Delivery flag), thus obviating the need
> >>>>> for a flood of jabber:iq:last requests.
> >>>>
> >>>> How about emphasizing the first option as a SHOULD?  This would
> >>>> hopefully encourage new servers to always reply, while not causing
> >>>> existing servers to become non-compliant.
> >>>
> >>> On the other hand, usually just 1/3 of my roster is online. So if
> >>> server starts sending presence for all contacts, initial "presence
> >>> flood" from the server increases 3 times.
> >>
> >> So do I take that as an objection to the modified text in rfc3921bis?
> >
> > Not an objection. But I am a bit worried by this change when I look at
> > my roster. However, at the same time I know that my roster is most
> > probably not a very typical one. Do we have any stats? What's the
> > percent of offline contacts? And what's typical roster size? Maybe it
> > doesn't matter that presence list increases 3 times if this means
> > increasing from 3 to 9 presence stanzas?
> I have 1770 people in my roster, so yes I'm concerned. :)
> I'll look up some stats on the jabber.org service to see what the
> average roster size is.

It seems funny that it should be a concern if all of your contacts are 
available at the same time.  It is possible for it to happen, and your client 
and internet connection shouldn't explode if it does.  However, maybe it is 
best to optimize out the offline contacts, if a presence response from an 
offline contact isn't useful enough to justify the increase in traffic.

My interest in having the server return a presence response for every contact 
was to aid in determining when a client login is "complete".  Right now 
there's really no way to know when a client is finished receiving an initial 
list of presence.  Clients often want to give the user a notification when 
presence activity changes, but only for changes after the initial list.  Psi 
considers the initial presence list to be received once 10 seconds have 
passed after the roster was received.  This is, of course, not very accurate, 
and when Peter takes more than 10 seconds to login, probably 1000 contacts 
trigger sound events.  However, maybe there's a better solution to the 
initial presence list problem.

That clients may want jabber:iq:last information available for all contacts, 
and without polling for it, is valid, IMO.  It relates very much to the 
desire to have jabber:iq:version information without polling.  I smell a 
push-based solution ahead...


More information about the JDev mailing list