[Bug 32125] Should support auth using captcha

[bugzilla-daemon at freedesktop.org]

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

--- Comment #32 from Dario Freddi <drf54321 at gmail.com> 2012-02-09 02:39:09 PST ---
(In reply to comment #30)
> (In reply to comment #21)
> > Attached comes a patch to tp-qt to support PropertiesChanged.
> 
> I don't think this blocks an initial implementation of captchas: at the spec
> design stage we only need to know that it's possible, we don't necessarily need
> to get it into a library and update that library. (A first Qt client
> implementation of captchas could just use QDBusConnection::connect directly, in
> the Handler - that's not a high-level API or anything, but it'd work.)

Indeed not - actually, I already fixed my code using an old tp-qt to support
that in a different way.

> 
> (In reply to comment #22)
> > If I understood correctly (please correct me if I am wrong) PropertiesChanged
> > is not interface specific, so adding it to AbstractInterface would mean that we
> > would need to filter for interface name before emitting
> > AbstractInterface::propertiesChanged. It also means we would need to connect to
> > the same signal multiple times without any need if we want to handle
> > propertiesChanged in multiple interfaces.
> 
> PropertiesChanged is emitted from the Properties interface, regardless of the
> interface whose properties are changing, but the intention in its design was
> that you use a D-Bus match rule containing
> arg0="org.freedesktop.Telepathy.Channel.Interface.CaptchaAuthentication" (or
> whatever) to listen for it, which makes it interface-specific again.
> 
> Unfortunately, QDBusConnection::connect doesn't seem to support arg0-matching
> in match rules yet... so unless/until it does, yes, you'll have to filter
> client-side.
> 
> Connecting to the signal multiple times isn't really going to be significantly
> more expensive than connecting once, unless QtDBus' data structures are less
> efficient than I thought: the underlying D-Bus message is only delivered once,
> and QtDBus will call all the slots to which it's relevant.

All the structures are implicitly-shared, so the overhead should be
trascurable. I am also quite sure you are right about QDBusConnection::connect

> 
> If QtDBus is ever going to support arg0 match rules, we should be careful that
> the telepathy-qt API we provide for this doesn't rule out making use of them to
> avoid unnecessary message delivery (so the API should look like "subscribe to
> PropertiesChanged for interface X on this Tp::DBusProxy", not "subscribe to
> PropertiesChanged on this whole Tp::DBusProxy").

Just to make it clear, in the end I suppose you favorable towards keeping this
in AbstractInterface (+ filtering based on the interface, and eventually using
arg0 in the future if ever), or did I misunderstand you and you prefer Andre's
approach?

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