[jdev] My GSoC project : to continue the PyMSNt development.
Daniel.Henninger at jivesoftware.com
Tue Apr 8 13:08:04 CDT 2008
> 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
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.
On 4/8/08 1:40 PM, "Peter Saint-Andre" <stpeter at stpeter.im> wrote:
> Sander Devrieze wrote:
>> 2008/4/8, Peter Saint-Andre <stpeter at stpeter.im>:
>>> 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
More information about the JDev