I'm afraid I'm not. I loath merged projects like that. Sorry to be a
party pooper.
Daniel
--
"The most addictive drug in the world is music."
- The Lost Boyz
> I'm all for starting out with merging PyMSNt, PyAIMt, and PyICQt into
> one project. Once that is done, we can move from there.
>
> On Jul 24, 2005, at 12:25 PM, Sander Devrieze wrote:
>
>> Hi,
>>
>> I have an idea for the Python-based Jabber transports. What about
>> combining
>> transports into one project? This new project will become the
>> server side
>> counterpart of multiprotocol clients like Gaim and Kopete.
>>
>> How this can be done? (some ideas, not all needs to be applied (at
>> once) of
>> course):
>> * a name for the project: maybe PyTransports?
>> * a logo for the project
>> * a Drupal-based website
>> * _one_ mailing list and MUC room for all "plugins" with many
>> people in it and
>> logs/archives
>> * one, consistent documentation base
>> * similar configuration files or even having only one configuration
>> file for
>> all transports (splitted in general options and plugin specific
>> configuration
>> options)
>> * similar string database for translators
>> * using the same Python libraries
>> * one common SVN repository
>> * releasing all this as one package with a plugin for every transport
>>
>> A few short-term advantages:
>> * coders of all transports can collaborate more easily
>> * translators need to translate/update only one file (less strings to
>> translate)
>> * Jabber transports will become more userfriendly as they all will
>> have the
>> same configuration file style and/or the same library dependency
>> (if users
>> can setup one transport, they can setup all)
>> * less documentation is needed and nearly all can be exchanged
>> between the
>> different transports
>> * distribution packagers only need to create one package to have
>> support for a
>> lot transports in their distribution. Of course they always can opt
>> to split
>> it in pytransports-core, pytransports-aim,... (result: more
>> distributions
>> will add pytransports as the total userbase of the different projects
>> together is bigger than the current projects on their own)
>> * more eyes will look to the same sourcecode
>> * easy to adapt protocol changes fastly in all transport plugins
>> -->in general: coders, users, documentation writers, webmasters,
>> packagers,
>> and translators can work together
>>
>> Some long-term advantages:
>> * competing against multi-protocol clients like Gaim and Kopete
>> (especially
>> when a small and easy-to-install package is created that includes
>> PyTransports and a small server like xmpppy that runs out-of-the-
>> box a Jabber
>> server on localhost with all transports. This opens the way for
>> Jabber-only
>> clients to have some proprietary network features that are now a
>> monopoly of
>> the multi-protocol clients). (As I already explained on
>> http://mail.jabber.org/pipermail/jadmin/2005-May/021144.html )
>> * more users and contributors for the PyTransports project (new
>> ones *and*
>> people who were involved in the multi-protocol client projects before)
>> * more people using Jabber
>> * PyTransports project members can ask/write JEPs when they are
>> needed to
>> bring proprietary network functionality to the Jabber world
>> * more transports will be created as it is more easy (new coders do
>> not need
>> to write the same amount of code and docs, to maintain a website,
>> to announce
>> new releases, to setup a mailinglist. They also easily can look to the
>> existing plugins as they will act nearly the same.)
>> * advanced and more difficilt things can become availaible (e.g. a web
>> interface for all the transport plugins)
>>
>> Goals:
>> (1) Making the Jabber community stronger,
>> (2) by accelerating the development of Jabber technologies,
>> (3) by increasing the utility of Jabber-only clients,
>> (4) and by copying (while improving!) features non-existant
>> in the
>> Jabber world, from the other networks.
>> (5) by luring users of the competing networks to the Jabber world,
>> (6) by making switching to Jabber more easy.
>>
>> Competition (in the order I think the project best "attacts" them):
>> (1) Open source clients that connect directly to non-Jabber
>> networks (and
>> especially to proprietary ones)
>> (2) Same as (1), but closed source clients.
>> (3) The (proprietary) instant messaging networks.
>> (4) Transports outside this project.
>>
>> A possible strategy ("Community Bodyshopping"):
>> (1) Make the new PyTransports project.
>> (2) Create a plugin for the most bad maintained or non-existing
>> protocol
>> plugin of some (or all) open source multi-protocol clients.
>> (3) Make this plugin much better than the multi-protocol client
>> plugins.
>> (4) Eventually contribute code to the Jabber plugins from the multi-
>> protocol
>> client projects to improve their Jabber support and to make it very
>> easy to
>> use the PyTransports plugin.
>> (5) Promote the usage of reaching this network via Jabber/
>> PyTransports instead
>> of via the plugin in the multi-protocol clients.
>> (6) Target: get all users and contributors that used the multi-
>> protocol client
>> plugin before to the Jabber community (Jabber ID, PyTransports, JEP
>> writing,...) so that the multi-protocol plugins for this network
>> will become
>> unmaintained and finally disappear in new versions (remark: it can be
>> possible that coders from the multi-protocol project that are doing
>> other
>> protocol plugins, don't like to drop this protocol plugin. Thus
>> they maybe
>> will invest their time - that they otherwise had spent on their
>> plugin! - to
>> make necessary updates for the plugin. But this might be not enough
>> to keep
>> the whole client stable/looking professional/secure (which is a
>> good thing
>> for Jabber-only clients!).
>>
>> Possible projects for such a merger:
>> * http://msn-transport.jabberstudio.org/ (PyMSNt)
>> * http://blathersource.org/ (PyAIM-t and PyICQ-t)
>> * http://xmpppy.sourceforge.net/ (Yahoo transport, IRC transport,
>> xmppd.py can
>> be maybe used for the mini local Jabber server idea)
>> * http://jmc.jabberstudio.org/ (Jabber Mail Component)
>> * http://jabberstudio.org/projects/jjigw/project/view.php (Jajcus'
>> Jabber to
>> IRC Gateway)
>>
>> --
>> Mvg, Sander Devrieze.
>>
>> xmpp:[EMAIL PROTECTED] ( http://jabber.tk/ )
>> _______________________________________________
>> py-transports mailing list
>> py-transports@blathersource.org
>> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>>
>
>
>
> __________________
> Robert Quattlebaum
> Mobile: +1(425)443-6785
> eMail: [EMAIL PROTECTED]
> Jabber: [EMAIL PROTECTED]
> MSN: [EMAIL PROTECTED]
> AIM: rquat2
> yahoo: robert_quattlebaum
> ICQ: 1454810
>
>
>
> _______________________________________________
> py-transports mailing list
> py-transports@blathersource.org
> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>
>
>
