[Telepathy] TransportHander API proposal

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(I haven't had a chance to review all the API in detail, so this is not
exhaustive.)

On Tue, 15 Apr 2008 at 10:56:07 +0300, Alberto Mardegan wrote:
>    in the branch 
> http://people.collabora.co.uk/~mardy/darcs/tp-spec-mardy-conditions/ 

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
  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 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
  integration anyway).

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
Telepathy's scope).

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

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.

    Simon
-----BEGIN PGP SIGNATURE-----

iD8DBQFIBIoRWSc8zVUw7HYRAgaEAKCGwhuuJBZIANLFnxd2gSbkOrkcowCguF2D
D41oIayR3CmPuqchDTozNc8=
=U0AX
-----END PGP SIGNATURE-----