[Bug 28230] Should query bare JID to check if PEP is supported

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28230

--- Comment #3 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2010-05-28 06:15:54 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > Here is a start of a branch fixing that:
> > http://git.collabora.co.uk/?p=user/cassidy/telepathy-gabble;a=shortlog;h=refs/heads/location
> > 
> > It doesn't block the transition state and doesn't add OLPC interfaces for now.
> > 
> > Note that with this branch it still don't work with my server :(
> > According to the XEP, the server is supposed to return:
> >     <identity category='pubsub' type='pep'/>
> > but I receive instead:
> >     <identity category='pubsub' type='service'/>
> > 
> > I guess that's an ejabberd bug so I opened
> > https://support.process-one.net/browse/EJAB-1238
> 
> +  if (!_gabble_connection_send_with_reply (conn, msg, set_location_sent_cb,
> +        G_OBJECT (conn), NULL, NULL))
> 
> if you pass NULL as the cb to send_with_reply it squashes the unhandled IQ
> warning without needing a no-op function.
> 
> Given that you do actually use the callback in the next commit, just squash
> those two commits together?

squased.

> Any particular reason for the bonus underscore in bare_jid__disco_cb ?

oops. Fixed.

> MyXmppStream is a terrible name.

renamed.

> +    try:
> +        conn.Location.SetLocation({'lat': 0.0, 'lon': 0.0})
> +    except dbus.DBusException:
> +        pass
> +    else:
> +        assert False, "Should have had an error!"
> 
> call_async(...)
> q.expect('dbus-error', error_name=cs.NOT_IMPLEMENTED)

Oh didn't know (I didn't gabble since a while). Done.

> would be clearer and test more and be shorter.
> 
> +    _, _, e = q.expect_many(
> +        EventPattern('stream-iq', iq_type='set',
> +            query_ns=ns.PUBSUB),
> +        EventPattern('dbus-signal', signal='StatusChanged',
> +            args=[cs.CONN_STATUS_CONNECTED, cs.CSR_REQUESTED]),
> +        EventPattern('stream-iq', iq_type='get', to='test at localhost',
> +            query_ns=ns.DISCO_INFO)
> +        )
> 
> We only care about the last one, so why expect the others? (Particularly given
> that we shouldn't move to Connected before discoing ourself: see below.)
> 
> (In reply to comment #0)
> > We should then disco our own bare jid as well. This lead to a question: should
> > we block the transition to the CONNECTED state until we received the reply of
> > this disco (as we do for the reply of the server disco?).
> 
> Yes we should. It's not just the OLPC interfaces that depend on this: we
> recently added a property to the Location interface specifying whether or not
> SetLocation is supported
> (http://telepathy.freedesktop.org/spec/org.freedesktop.Telepathy.Connection.Interface.Location.html#org.freedesktop.Telepathy.Connection.Interface.Location.SupportedLocationFeatures).
> It's not implemented yet, but in order to implement it correctly we need to
> wait until we've discoed ourself.

Good point. I've done that.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.