[Bug 29606] Reduce number of needed Account becomeReady calls

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Aug 31 19:45:42 CEST 2010


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

--- Comment #5 from Olli Salli <ollisal at gmail.com> 2010-08-31 10:45:41 PDT ---
(In reply to comment #3)
> >   That would cover all situations, even the one that Simon pointed as we would
> > reuse objects everywhere. If I have a connection with FeatureRoster ready
> > already and someone wants to create a ClientRegistrar with the connection
> > having the FeatureCore only, there is no problem, as it won't have to
> > introspect Roster again (it's already there), and in case both want
> > FeatureRoster for eg, ReadinessHelper will take care of not
> > creating/introspecting the object again if the introspection started already.
> > 
> > In other words, I believe we should make factories private to the class and
> > have global objects that should be used everywhere.
> 
> Naa... :) That is actually approximately equivalent to one of the evolutions of
> my suggested solution approach to bug #29451 but as explained above and in the
> later bug #29451 comments I don't think that's a good idea anymore.
> 

Also, doing this only solves requesting features - it doesn't solve requesting
a specific (application-configurable) (sub)class. If the objects are all in
some library-global cache, what if the factory/AM/whatever for one
plugin/module wants subclass SkypeStyleCallUIConnection and the one for another
wants say XChatStyleIRCUIConnection - if we only have one instance, being able
to request different features from it doesn't help much if one module wants it
to be a SkypeStyleCallUIConnection and the other a XChatStyleIRCUIConnection.

And this is just assuming the only things ever configurable using factories
will be the subclasses and the features on them...

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



More information about the telepathy-bugs mailing list