[Bug 29451] Too many asynchronous setup steps needed for basic usage

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Aug 18 13:17:29 CEST 2010


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

--- Comment #7 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-08-18 04:17:29 PDT ---
(In reply to comment #6)
>    - AM options must include "don't make any Connections ready please" for
> account editing UIs etc which don't quite care about them

I don't like the sound of negative Features. At the moment, all Features are
positive, which means that sharing an object can only ever slow you down.

>    - Client API delays calling the application until the objects are ready

In telepathy-glib, it already waits for CORE on Account, Connection, Channel
(but not necessarily ChannelRequest and ChannelDispatchOperation). I
implemented this in a telepathy-glib branch; it's not very difficult.

>    - new AM features {Accounts,Connections}Ready

I hope that means "core-ready"? Perhaps the name could indicate that better -
AM::Feature::AccountCore?

>  - everything is object instance-specific, no library-global or
> bus-connection-wide state

Yay! :-)

>    - Client always waits the AM and sub-objects to be ready before attempting
> to look-up Account/Connection objects to share - them being ready and a channel
> to handle coming for an account/connection we don't see through the AM is
> probably warning() zone

Actually, I think this can happen under normal use, if the message sequence is
unlucky. This is why we have tp_account_ensure_connection(), for instance.

> Open issue: at which stages of the program's lifetime do we want to allow
> setting the subclasses

You can only set the factory at, or just after, construction of the owning
object, would be my vote.

I think the factory (choice-of-subclass mechanism) and the choice of
initially-prepared features should probably be distinct?

> and features?
>  - AM semantics for setting features could be either
>    a) just once, before calling becomeReady(Feature*sReady) on it for the first
> time, this way it can be synchronous, and it's guaranteed non-co-operative
> plugins etc can't add harmful extra delays semi-globally because just the host
> application can do it
>     or
>    b) always, and make it upgrade existing objects - this way it'll have to be
> a PendingOperation - is more flexible but also more dangerous? I'm not entirely
> convinced the latter holds true though
>     - make it add-only though to not confuse somebody having set it earlier on
> with new objects not having their desired features, and document that if the
> application wants say an "show avatars" menu toggle, it shouldn't use this and
> instead upgrade objects in the old-fashioned way if that is enabled
>     - for convenience, the AM becomeReady(SubObjects) calls should wait for
> these requested pendingoperations to be ready so it doesn't have to be done
> separately when initially setting up the object, similarly to a)
>  - but subclass definitely can't be settable after the first object constructed
> in either case


>  - Client semantics should be "new Client operations are delayed accordingly to
> the new settings, with no direct effect in Accounts and Connections given in
> earlier operations" (not direct as in: except through the fact that it can be
> the same object due to sharing)
>    - can set features whenever convenient, subclass only before first object is
> constructed - this means we should document it should be set before the Client
> is registered on the bus
>    - the Client Acc/Conn factory is unused if an AM is linked to it, except for
> the additional features to wait for, because all objects are available from the
> AM anyway so there is no conflict between the subclasses specified in the two
> factories

In telepathy-glib I made it "you can only add features, and you can only do
that until you export the Client on the bus with tp_base_client_register()". I
could relax that later if there's a need but it seems a good conservative
default.

> This general approach still might seem at odds with your concerns, so I'll try
> and defend my position next:

Time to press [Commit] before reading/responding, so I won't lose this comment
:-)

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



More information about the telepathy-bugs mailing list