From 5139e7c8d04f28cf5a964a7b35f47ba15a73ff99 Mon Sep 17 00:00:00 2001
From: Stephan Erb <steve-e@h3c.de>
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 f0f5069a43..9d4314cf92 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 86e78049ef..257a72f901 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=[]
-- 
GitLab