[Telepathy] TransportHander API proposal

[mikhail.zabaluev at nokia.com]

Hi,

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.

Best regards,
  Mikhail

>-----Original Message-----
>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-----
>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-----
>_______________________________________________
>Telepathy mailing list
>Telepathy at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/telepathy
>