[Pydonkey-general] I want some changes

[NeoOne]

1.) Redefining strategy:
It's nice to have an alround  p2p-API, but it doesn't help if it "could" 
support several protocols, but it doesn't because the efford is too much 
for 2 people.
Since JXTA isn't used very much, I also asked myself anyway, if it makes 
sense at all. There more then ten bittorrent clients at the moment. And 
the protocol is so simple that it won't cope with future p2p.

But it can't be the solution to write another lame edonkey-client, where 
we have emule, which is doing SYN-Floods at the moment and crashing 
servers because the programmers seem to be little hackers.

Third, I don't that simply implementing a new protocol would it be, 
because at the moment about a hundred p2p-networks with clients are 
implemented, but only Kazaa and eDonkey are used by the majority. Now 
where Kazaa is under attack and edonkey too (as I noticed when I 
filtered aus peerguardian IPs and recognized they are spying on me too) 
the user split away from Kazaa (24% or so by now).

I don't think that the future is to cope with as much protocols as one 
can get in one client. The future is: the strongest will survive!

So what does make a p2p-network interesting:
1.)  Many Users/Files
2.)  Great Throuput
3.)  Security/Anonimity
4.)  Stability/Scalability

So what does that mean for us:
- Our client should have an interface to one big network, which I would 
suggest is edonkey because the protocol is well know, not like 
fasttrack. So we have point 1 on the list.
- Next: it should make improvements on this network, that no other 
clients have, for the points 2-4.

I have ideas for that, if interested I'll tell later.
---------------------
2. We should split up the project into 4 main classes:
- p2pSocket (is already done)
- p2pFileManager (which can do all the filehandling for any p2p-protocol 
in a threaded way, on maybe an XML-Base, like I already posted the 
XML-Api once)
- p2pProtocol (which is almost that what's now py2peer)
- p2pDB (which is what I call PyBrain)

----------------------
3.)  Make the API easier
At the moment pysocket etc. look pretty much the same as twisted, but 
therefore we aren't twisted, so why don't put all in one class, with 
function everybody uses.
The normal User, using pysocket, will have problems to understand the 
method of it, as I had.

So why not a structure like this
class PySocket{

   def addvariable(variable, value) // function to set datacontainer to 
the class, used by the callback functions
 
   def TCPConnect(Address) // Extraoptions maybe
   def TCPListen(port)     // Extraoptions maybe

   def UDPListen(port)

   def AddBandwithControlCB(bwcontrolfunction)  // inherited from 
pysocket.bandwithcontrol

   def TCPSend(handle, data)
   def UDPSend(address,port)

   def datareceived(self, handle, data, contype)   // Is called when 
data was received, contype is 0 for TCP then handle is the filehandle, 
if 1 then UDP and handle=(ipadress, port)

   def packetiscomplete() // Is called when packet has completed
   def packetanalyzer(self, handle, data, contype, receivedonport)    
// Is called when data was received to test wheter a packet has completed
  
   def enableSSL(options) // options like "force SSL etc.", keyfile etc.

   def addSendFilter(filterfunction) // This function is called before 
data is send, could be used for compression etc.
   def addReceiveFilter(filterfunction) // This functions is called 
after data is received , could be used for compression etc.

Callbackfunctions could always be
I will have forgot something, but that's the basic concept.

-----------------------------
4.) I want a Forum and Chat for us
Our communication is laking. Since amessage.de went down, we aren't able 
to communicate anymore.
So I suggest a Forum with a chat function.
If you are saying yes, I'll install one which we can link to the homepage.

So much for now,
Spikeee