[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 #2 from Will Thompson <will.thompson at collabora.co.uk> 2010-05-28 04:50:34 PDT ---
(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?

Any particular reason for the bonus underscore in bare_jid__disco_cb ?

MyXmppStream is a terrible name.

+    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)

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.

-- 
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.