From 5139e7c8d04f28cf5a964a7b35f47ba15a73ff99 Mon Sep 17 00:00:00 2001 From: Stephan Erb Date: Wed, 24 Dec 2008 14:28:17 +0000 Subject: [PATCH] Add credits and remove outdated documentation from __init__.py --- src/common/xmpp/__init__.py | 32 ++++++++------------------------ src/common/xmpp/client.py | 3 +++ 2 files changed, 11 insertions(+), 24 deletions(-) diff --git a/src/common/xmpp/__init__.py b/src/common/xmpp/__init__.py index f0f5069a4..9d4314cf9 100644 --- a/src/common/xmpp/__init__.py +++ b/src/common/xmpp/__init__.py @@ -1,35 +1,19 @@ # $Id: __init__.py,v 1.9 2005/03/07 09:34:51 snakeru Exp $ """ -All features of xmpppy library contained within separate modules. -At present there are modules: -simplexml - XML handling routines -protocol - jabber-objects (I.e. JID and different stanzas and sub-stanzas) handling routines. -debug - Jacob Lundquist's debugging module. Very handy if you like colored debug. -auth - Non-SASL and SASL stuff. You will need it to auth as a client or transport. -transports - low level connection handling. TCP and TLS currently. HTTP support planned. -roster - simple roster for use in clients. -dispatcher - decision-making logic. Handles all hooks. The first who takes control over fresh stanzas. -features - different stuff that didn't worths separating into modules -browser - DISCO server framework. Allows to build dynamic disco tree. -filetransfer - Currently contains only IBB stuff. Can be used for bot-to-bot transfers. +Gajim maintains a fork of the xmpppy jabber python library. Most of the code is +inherited but has been extended by implementation of non-blocking transports +and new features like BOSH. -Most of the classes that is defined in all these modules is an ancestors of -class PlugIn so they share a single set of methods allowing you to compile -a featured XMPP client. For every instance of PlugIn class the 'owner' is the class -in what the plug was plugged. While plugging in such instance usually sets some -methods of owner to it's own ones for easy access. All session specific info stored -either in instance of PlugIn or in owner's instance. This is considered unhandy -and there are plans to port 'Session' class from xmppd.py project for storing all -session-related info. Though if you are not accessing instances variables directly -and use only methods for access all values you should not have any problems. +Most of the xmpp classes are ancestors of PlugIn class to share a single set of methods in order to compile a featured and extensible XMPP client. +Thanks and credits to the xmpppy developers. See: http://xmpppy.sourceforge.net/ """ import simplexml, protocol, auth_nb, transports_nb, roster_nb import dispatcher_nb, features_nb, idlequeue, bosh, tls_nb, proxy_connectors -from client_nb import * -from client import * +from client_nb import NonBlockingClient +from client import PlugIn from protocol import * -# vim: se ts=3: \ No newline at end of file +# vim: se ts=3: diff --git a/src/common/xmpp/client.py b/src/common/xmpp/client.py index 86e78049e..257a72f90 100644 --- a/src/common/xmpp/client.py +++ b/src/common/xmpp/client.py @@ -28,6 +28,9 @@ class PlugIn: Inherit to develop pluggable objects. No code change on the owner class required (the object where we plug into) + + For every instance of PlugIn class the 'owner' is the class in what the plug + was plugged. ''' def __init__(self): self._exported_methods=[]