[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. [Lars H]: I don't know what kind of logic that is, but it's definitely not mathematical. Optimistic logic, perhaps? The ''mathematical'' definition of "true" is that : A formula is ''true'' (for a particular model) if it is satisfied for every assignment of values from the model domain to the free variables in the formula. ---- ''See also:'' * [beep] ---- [Category Internet]