[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jabber-jdev
Subject:    Re: [jdev] Possible inconsistency with roster pushes
From:       "Vinod Panicker" <vinod.p () gmail ! com>
Date:       2007-10-31 9:36:03
Message-ID: a8f18ca30710310224s1a364a6dsfa168a87dd12604 () mail ! gmail ! com
[Download RAW message or body]

On 10/30/07, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> Vinod Panicker wrote:
> > On 10/29/07, Tomasz Sterna <tomek@xiaoka.com> wrote:
> >> Dnia 29-10-2007, Pn o godzinie 12:17 +0100, Michal 'vorner' Vaner pisze:
> >>> No, it doesn't. Look at mcabber. You can be unavailable and still keep
> >>> the connection. You can even send messages from unavailable resource.
> >> You're right.
> >> I definitely need to sleep more.
> >>
> >> But I would rather call it "bound" not "active". There may be no
> >> activity on bound connection. :-)
> >
> > The definition as per RFC is "active", hence I stated that.  I doubt
> > there's a need to define yet another state :-)
> >
> > But really, a resource can ping-pong between active and available
> > states by sending presence stanzas of available and unavailable
> > respectively.
> >
> > Instead of changing a particular implementation that does what seems
> > "right" and sends roster pushes to "active" resources instead of the
> > "available" ones, I'd like this to be part of the new spec - with
> > appropriate consensus, of course.
>
> What is the use case driving your desire to make this change? BTW, the
> spec (both RFC 3921 and rfc3921bis) says this is a SHOULD (not MUST). If
> you want to send roster pushes to active resources that have requested
> the roster, feel free to do so on an experimental basis and report back
> with your findings. I happen to think that the vast majority of clients
> don't hang around in the active-but-not-available state, so I doubt that
> there is a lot to be gained here. But again if you have some powerful
> use cases, please do share them.

I had provided a basic use case in my original post and also a edge
case that results in a wrong user experience.

If the RFC is not mandating that the resources have to be in the
available state, then I can change my implementation.

Regards,
Vinod.
[prev in list] [next in list] [prev in thread] [next in thread]