[Telepathy] TransportHander API proposal
simon.mcvittie at collabora.co.uk
Tue Apr 15 03:57:21 PDT 2008
-----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 connectivity
stuff, and so does ConnectionHandler (which doesn't seem to be ready for
review, tbh). I think they should be reviewed separately.
> I've been writing an API to be implemented by connectivity plugins to
> 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 avoid having
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 telepathy-mission-control
code - it'd seem simple to add some API by which the platform-specific part
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 whatever,
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 (Debian ifupdown,
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
I don't think this is a problem we want to be solving right now, particularly
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 implementation-
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-----
More information about the Telepathy