[Bug 38206] Tp::StreamTubeChannel (and subclasses) don't have unit tests

[bugzilla-daemon at freedesktop.org]

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

--- Comment #12 from Olli Salli <ollisal at gmail.com> 2011-07-07 08:55:22 PDT ---
+    virtual void processConnectionClosed(uint connectionId, const QString
&errorName,
+            const QString &errorMessage);
+

We can't add virtual methods to public classes unless we assume nobody has
subclassed them. Additionally, on some architectures the vtable layout might
change sufficiently to break even the virtual destructor invocation in the
SharedPtr<OutgoingStreamTubeChannel> destructor (which is inline, and hence in
client code).

So this has to be handled in some other way. I assume your goal here was to
keep the removed connection in the mappings until the signal has been delivered
to slots in client code? Just using Qt::QueuedConnection for the connect() call
in the original OutgoingStreamTubeChannel destructor would accomplish that.

+void PendingStreamTubeConnection::onChannelInvalidated(DBusProxy *proxy,
+        const QString &errorName, const QString &errorMessage)
+{

This could use a warning indicating that the accept operation failed because
the channel was invalidated with said error.

+ * When this capability is available, the stream tube can be accepted or
offered without any
+ * restriction on the access control on the other end.

What on earth is this supposed to mean? The access control used for the other
end never plays any role, no matter what the locally supported access controls.

Otherwise looks good now.

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