> I don't disagree from the client perspective. But my philosophy has > always been to make XMPP as great as it can be, then everyone else will > eventually decide that they need to use XMPP and not some proprietary > garbage.
I won't get into my diatribe about why I think that will never happen. Aside from saying why are people still using IE6 and even IE5? ;) I've always been a big proponent of "let them use what they want, we'll do what we can do make the world able to communicate better". That doesn't mean trying to tell someone "your client blows, use this instead". Personally I see no problem with transport work as part of the GSoC. HOWEVER I do agree that, to me, the greater spirit of the XMPP involvement would be to learn more about XMPP and improve upon it directly. Can that be done by improving upon existing transports? Maybe. "In an ideal world", it could be awefully nice to see a project in which some sort of XEP gets implemented and improved upon, or some sort of new XEP concept gets written. Either way, the PyMSNt project idea could always be suggested over in the Python GSoC stuff as well. Daniel On 4/8/08 1:40 PM, "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote: > Sander Devrieze wrote: >> 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. > > Yeah, but you don't have a vote. :P > >> 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." > > > Peter
