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/ ) From [EMAIL PROTECTED] Sun Jul 24 20:39:37 2005 From: [EMAIL PROTECTED] (Oleg Motienko) Date: Sun Jul 24 20:39:40 2005 Subject: [py-transports] Re: Russian characters with PyICQ-t? In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Hello. > I tested latest svn version of PyICQ-t, it seems like it works well with > vcard-encoding.patch and <encoding>windows-1251</encoding> in config.xml. But what about of decoding icq away status messages ? I'll test this more more precisely in couple of days. -- Regards, Oleg From [EMAIL PROTECTED] Sun Jul 24 21:50:46 2005 From: [EMAIL PROTECTED] (Oscar =?ISO-8859-1?Q?Hellstr=F6m?=) Date: Sun Jul 24 21:50:42 2005 Subject: [py-transports] PyICQ Updates In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On Fri, 2005-07-22 at 08:15 -0400, Daniel Henninger wrote: > Folk, > > I finally was able to relax and get some work done on PyICQ, so I applied > a wealth of patches and misc other modifications. They are in SVN now, or > you can also grab the latest tarball from > http://www.vorpalcloud.org/tarballs/. These include but are not limited > to rate limiter fixes, encoding fixes, and offline message fixes (both > outgoing and incoming). Many thanks to all of those who submitted > patches! Please test the code if you have a chance. I'm actually > concerned that part of it may not work with Twisted 2 very well. (there > was a domish.py modification and I haven't checked if Twisted 2 will > behave the same way) Important things to test are vcard lookups and > messages from folk with non-english characters. Does this mean that the issue with character encodings is supposed to be solved? Anyhow, I will install and run the latest tarball as soon as possible, not tonight, tired and let U know how it behaves. > > Daniel > -- Oscar Hellstr?m, [EMAIL PROTECTED] jid: [EMAIL PROTECTED] icq: 52604556 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://modevia.com/pipermail/py-transports/attachments/20050724/e595e964/attachment.pgp From [EMAIL PROTECTED] Mon Jul 25 02:49:38 2005 From: [EMAIL PROTECTED] (Daniel Henninger) Date: Mon Jul 25 02:49:35 2005 Subject: [py-transports] Re: Russian characters with PyICQ-t? In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> There have been a lot of changes merged into the current SVN. Please do try them out with the various encoding issues people were running into before. Daniel -- "The most addictive drug in the world is music." - The Lost Boyz > Hello. > >> I tested latest svn version of PyICQ-t, it seems like it works well with >> vcard-encoding.patch and <encoding>windows-1251</encoding> in >> config.xml. > > But what about of decoding icq away status messages ? > I'll test this more more precisely in couple of days. > > -- > Regards, > Oleg > _______________________________________________ > py-transports mailing list > [email protected] > http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > > >
