Revision f6a67901e79d8d35e6bf30f0766b2417740090b7

[Etan Reisner]

On Tue, Aug 28, 2007 at 08:03:58AM -0400, Nathan Walp wrote:
> Andreas Monitzer wrote:
> > First off, thank you for reviewing the code.
> >
> > On Aug 28, 2007, at 03:28, Nathan Walp wrote:
> >
> >> - I dislike implementing experimental JEPs in libpurple
> >
> > The problem is that the XSF is very slow in moving XEPs to more stable
> > states, it usually takes a few years. I asked people in the know about
> > all experimental XEPs I considered implementing before doing so. All of
> > them are not expected to change much or getting thrown out again. That's
> > the reason I didn't implement User Profile.
> > XEP-0115: Entity Capabilities has changed since I implemented it, the
> > implementation will need some modifications.
>
> This is *exactly* why I don't like implementing them.  They do change
> out from under you.  I would suggest we either put the experimental ones
> behind a #ifdef, or keep them in a branch until they mature a bit more.
>   Most of the ones that have been sitting for eternity have been doing
> so because they depend on PEP, which took its dear sweet time.  Now that
> PEP is wrapping up, I think we should start to see these trickle to
> Draft.  When they're Draft, and "stable" I'm usually more comfortable
> unleashing them upon the masses.

For the record, there has been a recent push by standards at -ians to
encourage XEP authors to publish implementations (at least partial ones)
of new XEPs, and further to encourage (despite the large warning at the
top of the XEP itself) people to implement non-Draft XEPs. This came about
as a result of some of the recent late-in-the-game changes to XEPs like
0045 and 0115. Suggestions I think are good because without them we get
poorly thought-out XEPs, or XEPs sitting and waiting forever.

That being said, I think a reasonable wait and some applied brain-power to
the likelihood of the XEP being useful/appropriate is necessary before
implementing any given Experimental XEP.

<snip>

> >> - for the gateway interaction stuff, we assume that anything in our
> >> roster w/o an '@' is a gateway.  Why don't we simply send a disco
> >> request to all such entries in the roster, so we can know for sure?
> >
> > You wouldn't be any wiser for nodes that are offline (even gateways can
> > be offline). I talked to stpeter about that at last year's SoC, there
> > simply isn't a proper solution for it.
> > Besides that, doing a disco#info storm is one of the main things
> > XEP-0115 is trying to avoid. That XEP only works when you have received
> > a presence packet from the peer, which is not the case when the gateway
> > is offline, but it is needed to recognize it as a gateway, so you can
> > tell it that you want to go online.
>
> Granted I haven't talked to stpeter about this, but I guess I don't
> understand why we wouldn't get a disco#info result from an "offline"
> gateway.  And we should be able to avoid the storm where possible by
> waiting a few seconds to receive presence from the gateways that we'll
> get it from, and then disco the rest.
>
> It seems to me (and by all means, correct me if I'm mistaken), that the
> only way we're going to have an "offline" gateway is if one of the
> following has happened:
>
> - We've purposefully logged out of it this session, and therefore
> already know it is a gateway.
> - We've just registered with it, so we already know it is a gateway.
> - The server is busted
> - It isn't a gateway.
>
> I'm not sure what the expected behavior is when a busted server comes
> back online, but otherwise, I don't see a problem with not assuming it
> is a gateway until we actually know.
>
> I don't use gateways, haven't used them in probably 7 or 8 years now
> (hence the lack of implementation up to this point ;-)), so if I've
> missed something, it won't surprise me terribly.

I've never used a gateway in my life nor do I know anything about the
protocol for them so I'm not really qualified to discuss that aspect of
things, but I think assuming anything about any roster item is broken. If
there is no other way reliably determine when something is a gateway then
I think the protocol for them is broken and I would rather not support it.
(I realize that doesn't help the Adium folks who seem to want to support
anything if they can at all do so, but assumptions that 'break' things are
bad and I don't think they belong in libpurple.)

That being said I am perfectly ok with only 'properly' presenting gateway
interaction information for roster entries that we can actually tell are
gateways and leaving it up to the user to use gateways that work (and
probably to provide New Instant Message-style dialogs for interacting with
arbitrary gateways).

<snip>

> -Nathan

	-Etan