Add credits and remove outdated documentation from __init__.py

This commit is contained in:
Stephan Erb 2008-12-24 14:28:17 +00:00
parent 6999e1bbb6
commit 5139e7c8d0
2 changed files with 11 additions and 24 deletions

View File

@ -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:
# vim: se ts=3:

View File

@ -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=[]