[Bug 29699] Tp::ChannelRequest incorrectly checks immutable properties

[bugzilla-daemon at freedesktop.org]

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

Olli Salli <ollisal at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |NOTABUG
           Severity|normal                      |blocker
                 CC|                            |ollisal at gmail.com

--- Comment #4 from Olli Salli <ollisal at gmail.com> 2010-09-19 23:51:42 PDT ---
The point of passing immutable properties never was that the object would
immediately be ready by the time the constructor returned. The immutable
properties were only ever intended to be an optimization for not having to do
GetAll in most cases when the introspection process kicks off. The thing is
that the supplied immutable properties may be insufficient and therefore the
normal introspection has to run - hence the application has to do becomeReady
and wait for it to finish (although it would finish immediately with sufficient
immutable props), just to handle the case of insufficient props correctly.

Besides, the CR still has to make its Account ready, which doesn't occur
immediately in most cases. HOWEVER, a related feature addition in 0.3.10 makes
the ChannelRequest given to you in addRequest reuse the Account from the rest
of your application, and only makes it ready if nobody else hasn't already.
This means less DBus traffic and it becoming ready quicker, but still, *you
need to call becomeReady*.

To reiterate: to make ReadyObjects like ChannelRequest become ready, *you have
to call becomeReady()* in general. However, the factory stuff from 0.3.9/0.3.10
removes the need to do this for Account and Connection objects - you can
instead set specific features on an Acc/ConnFactory to be always made ready for
you before Accs/Conns are signaled anywhere, including the Client methods.

I guess I could add a separate special-case thing similar to factories which
would essentially be a boolean you set on your AbstractClientHandler
implementation, to make the addRequest ChannelRequests always be ready using
becomeReady() before signaling an addRequest. It's either the library or the
app doing that BUT if you do it in your application, you can actually prepare
for errors in making the CR ready - the best we can do in the library is to
have another iWasGoingToGiveYouACRButItFailedWithThisError() hook to your
application, which I don't think is very clean. If you think this is still a
bug and we should add that boolean-y thing - which would mean that error-out in
making it ready would never signal anything to your application, reopen with
prio:high, severity:enhancement.

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