circle-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[circle] Proposed node.py structure


From: Paul Campbell
Subject: [circle] Proposed node.py structure
Date: Thu, 7 Oct 2004 11:49:22 -0700
User-agent: Mutt/1.5.6i

Here's my proposed node.py structure:

1. First, move it into a separate subdirectory. I'm calling it "core" for now
since this represents the DHT core. I also believe (not gotten to it yet) that
all of the various services functions should be moved into either "services"
or "plugins" and should be treated as plugins since in the strictest sense,
they are "optional". I'm fluid as to whether all plugins are considered
equals or not.

2. Move the various utility functions into a separate file. These are things
like the address mangling/demangling routines. They should be all the more
or less "self contained" functions.

3. Split off the RPC message handler functions into a separate class and into
a separate module. They're obviously not self-contained but they do represent
something of a separable function. So for right now, I stuffed them into
two classes. The overall message handler class is pretty much self contained.
The "local server" functions are not so clean, but I put them into a separate
class anyways. They are chained together into the Node class as a subclass
hierarchy.

4. Move the various functions in the main poll loop into their own respective
areas, and get rid of the central polling loop.

5. Upgrade the "Peer" class from a mere helper to a full fledged peer handling
class. It now does it's own polling. It also tracks the peer status and
calls "hashtable_activate" and "hashtable_deactivate" independently as needed.

6. Move all the various functions that are currently listed in the module
without a class into the Node class itself, when they belong there. This just
makes more sense since they are part of the DHT itself. If they are to be
marked private, simply use the standard Python tag for that (_name).

7. Strip out the RPC handling and make it a separate self-contained class.

8. Move the data handling and lookup functions out into a separate superclass,
although they should be subclassed just like the RPC handling functions. Then
they can be moved to a separate module pretty easily.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]