copyleftie
/
gajim-plural
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
src/common/xmpp/__init__.py
View File

@ -1,35 +1,19 @@
# $Id: __init__.py,v 1.9 2005/03/07 09:34:51 snakeru Exp $ # $Id: __init__.py,v 1.9 2005/03/07 09:34:51 snakeru Exp $
""" """
All features of xmpppy library contained within separate modules. Gajim maintains a fork of the xmpppy jabber python library. Most of the code is
At present there are modules: inherited but has been extended by implementation of non-blocking transports
simplexml - XML handling routines and new features like BOSH.
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.
Most of the classes that is defined in all these modules is an ancestors of 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.
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.
Thanks and credits to the xmpppy developers. See: http://xmpppy.sourceforge.net/
""" """
import simplexml, protocol, auth_nb, transports_nb, roster_nb import simplexml, protocol, auth_nb, transports_nb, roster_nb
import dispatcher_nb, features_nb, idlequeue, bosh, tls_nb, proxy_connectors import dispatcher_nb, features_nb, idlequeue, bosh, tls_nb, proxy_connectors
from client_nb import * from client_nb import NonBlockingClient
from client import * from client import PlugIn
from protocol import * from protocol import *
# vim: se ts=3: # vim: se ts=3:

3
src/common/xmpp/client.py
View File

@ -28,6 +28,9 @@ class PlugIn:
Inherit to develop pluggable objects. No code change on the owner class Inherit to develop pluggable objects. No code change on the owner class
required (the object where we plug into) 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): def __init__(self):
self._exported_methods=[] self._exported_methods=[]