[Bug 29973] TpClientChannelFactory interface and TpDefaultChannelFactory

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Sep 3 08:25:09 CEST 2010


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

--- Comment #4 from Olli Salli <ollisal at gmail.com> 2010-09-02 23:25:08 PDT ---
FYI, my most recent design for factory API in TpQt4 is (without the Qt/C++
subleties):

/*
 * Actually, most SharedPtr<DBusProxy> is really currently
SharedPtr<RefCounted> because of totally bonged class hierarchy, will change in
API/ABI break
 */

class DBusFactory
{
protected non-virtual methods:
    SharedPtr<DBusProxy> cachedProxy(busName, objectPath)
    {
        // Return proxy from the cache or NULL if not present
    }

    PendingReady *nowHaveProxy(proxy)
    {
        // Lots of dynamic casts and asserts etc because the current class
hierarchy sucks

        Features specificFeatures = featuresFor(proxy) // Will be fixed for
Acc/Conn, but variable for Channel, see later
        if (proxy not in cache) {
            // Put to cache, make sure it's removed from cache if invalidated
or destroyed in user code ie. weak pointer and invalidated() signal connection
        }

        if (prepare(proxy) != NULL && not yet completed the prepare of for this
instance)
            return PendingReady which first waits for the prepare() op to
complete, then makes the specificFeatures ready, if any
        else
            return PendingReady which just makes specificFeatures ready, if any
- if no features are set, not even Core is made ready, which is of benefit to
eg. account editing UIs which probably don't want to make Connections ready
although they're tampering with their respective Connections
    }

virtual methods:
    Features featuresFor(proxy) = 0
    PendingOperation *prepare(proxy) // By default, returns NULL PendingOp,
this is for future expansion / application-specific "always perform this"
actions only - obviously we could do such actions in the class constructors
themself if we wanted
}

class FixedFeatureFactory : DBusProxyFactory
{
public non-virtual methods:
    Features features()

    addFeature(feature)
    addFeatures(features)

    // By default, no features, not even Core

virtual implementations:
    featuresFor(proxy) {
        UNUSED(proxy)
        return set features
    }

    // No prepare()
}

class AccountFactory : FixedFeatureFactory
{
    PendingReady *proxy(busName, objectPath, connFactory, chanFactory)
    {
        SharedPtr<DBusProxy> proxy = cachedProxy(busName, objectPath)
        if (!proxy)
            proxy = Account::create(busName, objectPath, connFactory,
chanFactory)

        return nowHaveProxy(proxy)
    }
}

class ConnectionFactory : FixedFeatureFactory
{
    PendingReady *proxy(busName, objectPath, chanFactory) // Note that actually
chanFactory won't be used much at all in tp-qt4 Connection, but still there for
direct ensureChannel / createChannel and other misc
    {
        // Very similar to AccountFactory::proxy()
    }
}

class ChannelFactory : DBusProxyFactory
{
    // To enable channel class -specific subclasses
    void setClassCtorFunction(QVariantMap channelClass, Ctor ctor)
    // Ctor is essentially any function like ChannelPtr ctor(connectionProxy,
channelObjectPath, immutableProperties) ie. what TextChannel::create, etc. are
like anyway - so no need for any templated glue-generating magic (although
that'd be possible too if we want it at some stage)

    // To enable channel class -specific features
    Features classFeatures(QVariantMap channelClass)
    void addClassFeatures(QVariantMap channelClass, Features features)

    PendingReady *proxy(connectionProxy, channelObjectPath,
immutableProperties)
    {
        // Similar to Acc/ConnFactory proxy() but uses
immutableProperties-specific construction
    }

    ChannelFactoryPtr stockFreshFactory()
    {
         return ChannelFactory which constructs Channel subclasses provided in
TpQt4 proper (hence "stock") but makes no features ready on them (equivalent to
the old pre-factory behavior)
    }

virtual implementations:
    Features featuresFor(proxy)
    {
        // Digs the immutable properties out of the proxy, and returns channel
class -specific features accordingly
    }
}

etc.

where PendingReady is a class like

class PendingReady
{
    // Well because the current object hierarchy is bonged, this is
SharedPtr<RefCounted> until the API/ABI break, which sucks
    SharedPtr<DBusProxy> proxy()

signals:
    finished(this)
}

So you have the option of extracting the proxy() as soon as you get the
PendingReady out of the factory, but also can delay doing that until
finished(which is when the set features and prepare op are both finished). So
this makes it most like A) of your options. FWIW I think it's important, if
only for library internal use, that one can get to the proxy even before it's
fully ready.

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