tahoe-lafs/docs/codemap.txt
Zooko O'Whielacronx 59d6c3c822 decentralized directories: integration and testing
* use new decentralized directories everywhere instead of old centralized directories
 * provide UI to them through the web server
 * provide UI to them through the CLI
 * update unit tests to simulate decentralized mutable directories in order to test other components that rely on them
 * remove the notion of a "vdrive server" and a client thereof
 * remove the notion of a "public vdrive", which was a directory that was centrally published/subscribed automatically by the tahoe node (you can accomplish this manually by making a directory and posting the URL to it on your web site, for example)
 * add a notion of "wait_for_numpeers" when you need to publish data to peers, which is how many peers should be attached before you start.  The default is 1.
 * add __repr__ for filesystem nodes (note: these reprs contain a few bits of the secret key!)
 * fix a few bugs where we used to equate "mutable" with "not read-only".  Nowadays all directories are mutable, but some might be read-only (to you).
 * fix a few bugs where code wasn't aware of the new general-purpose metadata dict the comes with each filesystem edge
 * sundry fixes to unit tests to adjust to the new directories, e.g. don't assume that every share on disk belongs to a chk file.
2007-12-03 14:52:42 -07:00

65 lines
2.4 KiB
Plaintext

CODE OVERVIEW
A brief map to where the code lives in this distribution:
src/allmydata: the code for this project. When installed, this provides the
'allmydata' package. This includes a few pieces copied from
the PyCrypto package, in allmydata/Crypto/* .
Within src/allmydata/ :
interfaces.py: declaration of zope.interface-style Interfaces for most
components, also defines Foolscap RemoteInterfaces for
all remotely-accessible components
node.py: the base Node, which handles connection establishment and
application startup
client.py, introducer.py:
these are two specialized subclasses of Node, for users and the central
introducer, respectively. Each works by assembling a collection of services
underneath a top-level Node instance.
introducer.py: node introduction handlers, client and server
storageserver.py: provides storage services to other nodes
codec.py: low-level erasure coding, wraps the zfec library
encode.py: handles turning data into shares and blocks, computes hash trees
upload.py: upload server selection, reading data from upload sources
download.py: download server selection, share retrieval, decoding
dirnode2.py: implements the distributed directory nodes.
webish.py, web/*.xhtml: provides the web frontend, using a Nevow server
uri.py: URI packing/parsing routines
hashtree.py: Merkle hash tree classes
debugshell.py, manhole.py: SSH-connected python shell, for debug purposes
util/*.py: misc utility classes
test/*.py: unit tests
Both the client and the central introducer node runs as a tree of
(twisted.application.service) Service instances. The Foolscap "Tub" is one of
these. Client nodes have an Uploader service and a Downloader service that
turn data into URIs and back again.
The Uploader is given an "upload source" (which could be an open filehandle,
a filename on local disk, or even a string), and returns a Deferred that
fires with the URI once the upload is complete. The Downloader is given a URI
and a "download target" (an open filehandle, filename, or instructions to
provide a string), and fires a Deferred with a target-specific value when the
download is complete. The source/target API is intended to make it easy to
stream the incoming data to a media player or HTTP connection without having
to consume a lot of memory for buffering.