[Pydonkey-general] Current stuff ...

[joel vennin]

For now, i've separated the stuff in differents parts.

Common : 
   class to manage configuration file (preferences.py) of the client
   class to manage incoming packet, BufferProtocol (protocol.py) , this class 
try to catch and rebuild packet with the incoming stream. It's use by each 
class which dialog with edonkey protocol.
  class to manage "control" (control.py) of the client. Inside the code of the 
client there is some event, like client incoming, error message, incoming 
message, ...,  these messages are send to a telnet session or a GUI. There is 
the ControlInterfaceProtocol, each control client (telnet, gui) must 
inherited of this class. 

Console:
  class to manage telnet connection (command.py).

Donkey:
   Contains all the stuff around the edonkey protocol
        server.py: Contains all stuff around the server dialog. Send message to 
server and get response. ServerProtocol is the protocol with the server, 
ServerInformation is some information of a server, ServerFactory is used to 
connect a server, and server Manager which contains a list of server. It's 
possible to save and load server.met file.

        packet.py: Contains a class to build packet to send a the server or at 
a 
client.
        tag.py : Contains class to manage tag structure, IMPROVE IT, this class 
is 
not finish, we need remove TagBuilder, and replace it with TagStruct and 
TagManager.

        file.py: contains all stuff around file (check the MD4, manage Hash 
part of a 
file), split file in chunk ...
        search.py: contains all th stuff around the search action. Manage many 
search 
...
        opcode.py: contains all opcode 
        
        transfert.py: contains a first code to download something ...... 
IMPROVE IT 
!!!!!
                
At the root:
        apps.py build the client ....


All parts need to be improve, we need to document the code, and change a lots 
of code ;) About ClientInformation in donkey.client, maybe we need to move 
some ClientInformation in a new class in common.client ?

The current problem is that emule client doesn't send a QUEUE RANK when our 
client send a slot request ....

We need use a UML tool to design or redesign our client ...

I think we must concentrate our efforts on the core not on a GUI ...

So a first road map:
 1) clean the code
 2) document some code
 3) Find why a emule client doesn't want to send a QUEUE RANK
 4) Able to download and upload
 6) Add bandwidth limitation (download and upload)
 7) find good policies for the upload and download. I'm not for a credit 
system. But for an upload limitation ... we can discuss on it later .... I've 
several idea around this stuff to promote a big upload. Because if everybody 
allow big upload, everybody could have fast download.
 
I'm asking several question about file. Do you think we must respect .met, 
.part file format or create another format ?

Any suggest are welcome ...

jol