Version 9 of Peer to peer

Updated 2005-07-25 16:32:57 by escargo

Zarutian 2005-07-25-15:02 Okay I am going to make a simpe peer to peer system in Tcl

First of the spec:

'Functional specfication of simpleP2P'

Overview:

  • simpleP2P is a little program that demonstrates how to make a simple peer to peer system in Tcl
  • 'This spec is not, by any stretch of the imagination, complete.' All of the wording will need to be revised several times before it is finalized.

Scenarios:

  Scenario 1: Raoul
   Raoul is a programmer relativitly new to Tcl and wants to try something
   kewl with Tcl. Raoul doesnt want to install a big runtime on his machine,
   so he gets the tclkit for his platform of choice. He then downloads 
   simpleP2P.kit to the same folder (or if you prefere: directory) as his 
   tclkit executable is in. He drags the simpleP2P.kit over his tclkit 
   executable and therefor starts the simpleP2P application. Up pops the 
   console and a window showing him the built-in command manual for the
   application. He enters the command "listen 8050". Raoul IMs his buddy
   asking him to get tclkit and simpleP2P.kit and enter the command
   "connect raoul.cjb.net 8050"

Non-Goals:

  * we are not going to use XML to fromat messages between peers
  * simpleP2P wont support connecting through a proxy.
  * simpleP2P wont have a file search capability

... arrh I dont know how to write functional specs! But I sure wont give up. It will be done eventualy -Zarutian


When it comes to functional specs, I suggest that first you start with your requirements. What to you want it to do? What do you want it not to do?

Second, what policies do you want it to implement. (Using a queue is a policy; using a linked list is a mechanism. For functional specs, stay away from mechanisms.)

Third, think about tests. What test could you perform that would tell you if the implementation is performing correctly? (If you can't think of how to test it, then how can you tell if it's working or not?)

Fourth, this one a step that I invented myself (though I doubt it's completely original). Imagine an implementation of the requirements that meets the stated requirements, but is absurd in some way. (This is a mechanism for requirements solicitation that I had to use when an organization wanted something implemented, but they said that they had no requirements.) For example, what if whatever you implemented limited you to messages of 80 chars in length? What if you had to log in every time you wanted to send a message? What if you had to enter the name of the peer every time you wanted to send a message? You might not have thought to specify these, but they are probably requirements you have that you just didn't think to write down.

At Honeywell (at least in the now-dim past), they used to say that, Quality is conformance to written requirements. (It's kind of like mathematical logic, where you say that, Something is true if it cannot be proven to be false.) If you can have an implementation of your functional requirements that in fact does not function acceptably, then you forgot to specify some requirements.


See also:


Category Internet