cpython/Demo/pdist
Alexandre Vassalotti 1f2ba4b6da Rename the repr module to reprlib.
Merged revisions 63357 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk

........
  r63357 | alexandre.vassalotti | 2008-05-16 02:58:49 -0400 (Fri, 16 May 2008) | 2 lines

  Changed references to the reprlib module to use its new name.
........
2008-05-16 07:12:44 +00:00
..
FSProxy.py Run 2to3 over the Demo/ directory to shut up parse errors from 2to3 about lingering print statements. 2007-07-17 20:59:35 +00:00
RCSProxy.py Run 2to3 over the Demo/ directory to shut up parse errors from 2to3 about lingering print statements. 2007-07-17 20:59:35 +00:00
README restructured index somewhat 1995-06-23 22:11:18 +00:00
client.py #1535: rename __builtin__ module to builtins. 2007-12-02 09:40:06 +00:00
cmdfw.py remove most uses of list(somedict.keys()) in Demo scripts 2007-08-06 21:07:53 +00:00
cmptree.py Rename the repr module to reprlib. 2008-05-16 07:12:44 +00:00
cvslib.py remove most uses of list(somedict.keys()) in Demo scripts 2007-08-06 21:07:53 +00:00
cvslock.py Fix more exception slicing. 2008-01-06 21:13:42 +00:00
mac.py Run 2to3 over the Demo/ directory to shut up parse errors from 2to3 about lingering print statements. 2007-07-17 20:59:35 +00:00
makechangelog.py Run 2to3 over the Demo/ directory to shut up parse errors from 2to3 about lingering print statements. 2007-07-17 20:59:35 +00:00
rcsbump Merge p3yk branch with the trunk up to revision 45595. This breaks a fair 2006-04-21 10:40:58 +00:00
rcsclient.py Whitespace normalization. Ran reindent.py over the entire source tree. 2004-07-18 05:56:09 +00:00
rcslib.py Run 2to3 over the Demo/ directory to shut up parse errors from 2to3 about lingering print statements. 2007-07-17 20:59:35 +00:00
rcvs Change #! line to modern usage 1999-03-12 19:05:49 +00:00
rcvs.py Run 2to3 over the Demo/ directory to shut up parse errors from 2to3 about lingering print statements. 2007-07-17 20:59:35 +00:00
rrcs Change #! line to modern usage 1999-03-12 19:05:49 +00:00
rrcs.py remove most uses of list(somedict.keys()) in Demo scripts 2007-08-06 21:07:53 +00:00
security.py Run 2to3 over the Demo/ directory to shut up parse errors from 2to3 about lingering print statements. 2007-07-17 20:59:35 +00:00
server.py Rename the repr module to reprlib. 2008-05-16 07:12:44 +00:00
sumtree.py Run 2to3 over the Demo/ directory to shut up parse errors from 2to3 about lingering print statements. 2007-07-17 20:59:35 +00:00

README

Filesystem, RCS and CVS client and server classes
=================================================

*** See the security warning at the end of this file! ***

This directory contains various modules and classes that support
remote file system operations.

CVS stuff
---------

rcvs			Script to put in your bin directory
rcvs.py			Remote CVS client command line interface

cvslib.py		CVS admin files classes (used by rrcs)
cvslock.py		CVS locking algorithms

RCS stuff
---------

rrcs			Script to put in your bin directory
rrcs.py			Remote RCS client command line interface

rcsclient.py		Return an RCSProxyClient instance
			(has reasonable default server/port/directory)

RCSProxy.py		RCS proxy and server classes (on top of rcslib.py)

rcslib.py		Local-only RCS base class (affects stdout &
			local work files)

FSProxy stuff
-------------

sumtree.py		Old demo for FSProxy
cmptree.py		First FSProxy client (used to sync from the Mac)
FSProxy.py		Filesystem interface classes

Generic client/server stuff
---------------------------

client.py		Client class
server.py		Server class

security.py		Security mix-in class (not very secure I think)

Other generic stuff
-------------------

cmdfw.py		CommandFrameWork class
			(used by rcvs, should be used by rrcs as well)


Client/Server operation
-----------------------

The Client and Server classes implement a simple-minded RPC protocol,
using Python's pickle module to transfer arguments, return values and
exceptions with the most generality.  The Server class is instantiated
with a port number on which it should listen for requests; the Client
class is instantiated with a host name and a port number where it
should connect to.  Once a client is connected, a TCP connection is
maintained between client and server.

The Server class currently handles only one connection at a time;
however it could be rewritten to allow various modes of operations,
using multiple threads or processes or the select() system call as
desired to serve multiple clients simultaneously (when using select(),
still handling one request at a time).  This would not require
rewriting of the Client class.  It may also be possible to adapt the
code to use UDP instead of TCP, but then both classes will have to be
rewritten (and unless extensive acknowlegements and request serial
numbers are used, the server should handle duplicate requests, so its
semantics should be idempotent -- shrudder).

Even though the FSProxy and RCSProxy modules define client classes,
the client class is fully generic -- what methods it supports is
determined entirely by the server.  The server class, however, must be
derived from.  This is generally done as follows:

	from server import Server
	from client import Client

	# Define a class that performs the operations locally
	class MyClassLocal:
		def __init__(self): ...
		def _close(self): ...

	# Derive a server class using multiple inheritance
	class MyClassServer(MyClassLocal, Server):
		def __init__(self, address):
			# Must initialize MyClassLocal as well as Server
			MyClassLocal.__init__(self)
			Server.__init__(self, address)
		def _close(self):
			Server._close()
			MyClassLocal._close()

	# A dummy client class
	class MyClassClient(Client): pass

Note that because MyClassLocal isn't used in the definition of
MyClassClient, it would actually be better to place it in a separate
module so the definition of MyClassLocal isn't executed when we only
instantiate a client.

The modules client and server should probably be renamed to Client and
Server in order to match the class names.


*** Security warning: this version requires that you have a file
$HOME/.python_keyfile at the server and client side containing two
comma- separated numbers.  The security system at the moment makes no
guarantees of actuallng being secure -- however it requires that the
key file exists and contains the same numbers at both ends for this to
work.  (You can specify an alternative keyfile in $PYTHON_KEYFILE).
Have a look at the Security class in security.py for details;
basically, if the key file contains (x, y), then the security server
class chooses a random number z (the challenge) in the range
10..100000 and the client must be able to produce pow(z, x, y)
(i.e. z**x mod y).