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
> [email protected]
> 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


Reply via email to