-----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 [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
