2008/4/8, Peter Saint-Andre <[EMAIL PROTECTED]>: > I am not convinced that working on transports is an > appropriate topic for the Google Summer of Code. I plan to give my votes > to projects that improve or extend XMPP itself, not provide bridges to > closed technologies.
I do not agree on this. Good transports are advantageous for XMPP. As I already wrote on http://coccinella.im/whytransportsmatter --> "More and better transports are needed to allow XMPP clients to compete effectively with the key feature of multiprotocol clients: interoperability with multiple closed networks. Multiprotocol clients can't innovate as fast as XMPP clients can (see above), so we can tackle them on the interoperability feature which is XMPP's core feature." Every user that uses a transport instead of the official client to access the closed network or instead of a multiprotocol client *contributes* to XMPP in these ways: * Network effects: even if this user only uses the XMPP client to communicate with people on closed networks he *needs* an XMPP account on a server. There are even transports that can detect if one of your contacts on a closed network is also using a transport so that you can add his XMPP ID instead! * Testing: every additional user may find bugs in the XMPP client or the XMPP server. Fixing these bugs will help the broader XMPP community. * Reducing client choice and user experience on closed networks: a stronger focus of the XMPP community on transports will reduce client choice and user experience on closed networks. This will increase the value of XMPP for users. See my article for more information on this one or ask me if you don't understand this. * Attracting more developers to the XMPP community: a user using an XMPP client, an XMPP account on an XMPP server, and a transport may attract people to contribute to all of these. If this user would have used a multiprotocol client, this will only attract people to contribute to the closed protocol plugin of this multiprotocol client and the user interface of this client. Such contributions will benefit the XMPP community close to zero: only contributions to the user interface may be beneficial also this also may be seen as a disadvantage (e.g. ugly XMPP-specific dialogs in Adium). -- Mvg, Sander Devrieze.
