[Telepathy] TransportHander API proposal
mikhail.zabaluev at nokia.com
mikhail.zabaluev at nokia.com
Tue Apr 15 04:35:56 PDT 2008
I agree that most of it is too complicated and we are not going to need it (and when we do, the requirements will be different enough to warrant a redesign anyway). See YAGNI principle.
I'd retain Conditions, though, as an generic way for accounts to specify named conditions that:
1) will be requested from plugins to resolve when the account is brought online manually;
2) will be checked for accounts that are configured to connect automatically.
(Note that any binary algebra except AND-ing the account conditions is gone; sophisticated logic would be encapsulated in plugins, _if necessary_).
I think the Plugin property in that interface is unnecessary, as it serves a special case of binding to one plugin. That can be done using conditions alone.
The initial plugin SPI to handle conditions can be binary-only for starters, after implementing that we'll have some experience to specify it for long-running DBus daemons, _if necessary_.
The skeletal condition plugin API I can see, based on an earlier proposal for account manager:
- MonitorConditions method: a subscription to state notifications for a set of conditions pertaining to this plugin.
- SatisfyConditions method: initiates a request to satisfy conditions.
- ConditionsChanged signal: emitted as a result of satisfying requested conditions. Also, emitted when external events cause any monitored conditions to change.
- ConditionRequestFailed signal: emitted if one of the conditions could not be satisfied for a request.
>From: telepathy-bounces at lists.freedesktop.org
>[mailto:telepathy-bounces at lists.freedesktop.org] On Behalf Of
>ext Simon McVittie
>Sent: Tuesday, April 15, 2008 1:57 PM
>To: telepathy at lists.freedesktop.org
>Subject: Re: [Telepathy] TransportHander API proposal
>-----BEGIN PGP SIGNED MESSAGE-----
>(I haven't had a chance to review all the API in detail, so this is not
>On Tue, 15 Apr 2008 at 10:56:07 +0300, Alberto Mardegan wrote:
>> in the branch
>Can you please separate your branch into orthogonal changes? Your
>changes to Account.xml seem to be entirely unrelated to the
>stuff, and so does ConnectionHandler (which doesn't seem to be
>review, tbh). I think they should be reviewed separately.
>> I've been writing an API to be implemented by connectivity
>> report informations about connectivity events and to respond to
>> connectivity request.
>Why do connectivity plugins need to be services? Isn't MC already a
>service? There's no point in inventing long-running processes if they
>don't actually gain us anything (particularly if, unlike Telepathy
>connection managers, they consume memory even when not in use).
>As far as I can see, there are two main platforms that MC
>should work on:
>* Embedded devices like, er, the ones you're developing for
>:-) which have
> a single "official" connectivity API and probably want to
> unnecessary processes
> These would probably be better served by having dlopenable
>plugins, or just
> some #ifdef'd code, in the AccountManager implementation.
> Maemo already has osso-mission-control, which is a proprietary,
> platform-specific wrapper around the free, generic
> code - it'd seem simple to add some API by which the
> of MC could tell the generic part what conditions are in effect.
> Other embedded platforms could even use this API too, by writing a
> hypothetical olpc-mission-control or moko-mission-control or
> that wraps telepathy-mission-control in the same way!
>* Linux desktops, where we can't mandate or require that users have any
> particular method of getting connectivity; the connectivity mechanism
> might be a daemon (pppd, NetworkManager, netconf) or not
> whereami, Red Hat sysconfig), and we can't rely on being
>able to patch
> TransportHandler code into every implementation anyway.
>However, what we
> *can* pretty much rely on is that we can provide shell
>scripts that will
> be run at various stages of connecting/disconnecting; those shell
> scripts can communicate using dbus-send if necessary (this would
> require that the AM implementation listened on the system bus,
> probably, but that's OK, it'd need to do that for NetworkManager
> integration anyway).
>I don't think this is a problem we want to be solving right
>for the more generic "on the desktop" case (it seems rather outside
>The important thing from the Telepathy point of view is that the AM
>implementation gets hold of this information somehow - "in an
>implementation-specific way" is good enough, for everyone except the AM
>and connectivity-provider implementors - and does the right thing in
>I think it's fine to have code in the AM implementation (i.e. Mission
>Control or Decibel) that gathers connectivity info in an
>and platform-specific way. When/if we have a genuine use case for
>something more elaborate, *then* we can consider standardizing APIs.
>-----BEGIN PGP SIGNATURE-----
>-----END PGP SIGNATURE-----
>Telepathy mailing list
>Telepathy at lists.freedesktop.org
More information about the Telepathy