diff options
author | Sam T <pxqr.sta@gmail.com> | 2013-07-21 11:15:23 +0400 |
---|---|---|
committer | Sam T <pxqr.sta@gmail.com> | 2013-07-21 11:15:23 +0400 |
commit | 930ca350bafacf1c4c393776f1408293e3beb8d5 (patch) | |
tree | cb71f102f7bb0f4daa78e9a25a5ef7ffb322dd93 /README.md | |
parent | 944b8bfb6959944c607a2f9bd7af42fd654e5d32 (diff) |
~ Move beps status to separate file.
Diffstat (limited to 'README.md')
-rw-r--r-- | README.md | 49 |
1 files changed, 1 insertions, 48 deletions
@@ -10,61 +10,14 @@ same time provide both: | |||
10 | Currently it provides serialization and deserealization of core | 10 | Currently it provides serialization and deserealization of core |
11 | datatypes, some widely used routines and core types. | 11 | datatypes, some widely used routines and core types. |
12 | 12 | ||
13 | |||
14 | ### Status | 13 | ### Status |
15 | 14 | ||
16 | The protocol has many extensions(more precisely enchancements, but | 15 | See list of implemented [BEPs](BEP.md). |
17 | we'll use that word) and it's seems like no one will want to use just | ||
18 | core protocol, at least I'm not. Any modern application that uses | ||
19 | bittorrent protocol in any way will use some subset of extensions. | ||
20 | Thus it's reasonable to implement at least some part of widely used | ||
21 | extensions here, so we could provide nice high level API and well | ||
22 | integrated interface. | ||
23 | |||
24 | This section should keep track current state of package in respect of | ||
25 | BEP's. Please _don't_ use this list as issue or bug tracker or TODO | ||
26 | list or anything else: when in doubt don't change the table. | ||
27 | |||
28 | In order to keep table compact we describe table layout at first: | ||
29 | |||
30 | * **BEP #** — Just number of enchancement. | ||
31 | * **Title** — Full official enchancement name. | ||
32 | * **Modules** — modules that _directly_ relates to the BEP. This is where | ||
33 | BEP implemented, where we should look for the BEP. If a module has | ||
34 | only changes due to integration with the BEP then it _should not_ be | ||
35 | listed in the **Modules** list. | ||
36 | * **Status** — is the current state of the BEP. Status lifecycle has the | ||
37 | only way: Want -> Implemented -> Tested -> Integrated -> Done. You | ||
38 | might use (A -> B) to indicate intermediate steps. Note that | ||
39 | implemented _doesn't_ means that BEP is ready to use, it _will_ be | ||
40 | ready to use only after it pass Tested, Integrated and finally | ||
41 | becomes Done. | ||
42 | |||
43 | We should try keep table in order of priority, so first BEPs should be | ||
44 | are most important and last BEPs are least important. (but important | ||
45 | too) | ||
46 | |||
47 | | BEP # | Title | Modules | Status | ||
48 | |:-----:|:------------------------------------------:|:------------------------------------|:----------- | ||
49 | | 3 | The BitTorrent Protocol Specification | Data.Torrent | Implemented | ||
50 | | | | Network.BitTorrent.Peer | | ||
51 | | | | Network.BitTorrent.PeerWire | | ||
52 | | | | Network.BitTorrent.Tracker | | ||
53 | | 4 | Known Number Allocations | Network.BitTorrent.Extension | Want -> Implemented | ||
54 | | 20 | Peer ID Conventions | Network.BitTorrent.Peer.ID | Want -> Implemented | ||
55 | | | | Network.BitTorrent.Peer.ClientInfo | | ||
56 | | 9 | Extension for Peers to Send Metadata Files | | Want | ||
57 | | 23 | Tracker Return Compact Peer Lists | Network.BitTorrent.Tracker.Protocol | Implemented | ||
58 | | | | Network.BitTorrent.PeerWire.Message | | ||
59 | | 5 | DHT | | Want | ||
60 | | 6 | Fast Extension | Network.BitTorrent.PeerWire.Message | Want -> Implemented | ||
61 | |||
62 | 16 | ||
63 | ### Documentation | 17 | ### Documentation |
64 | 18 | ||
65 | For documentation see haddock generated documentation. | 19 | For documentation see haddock generated documentation. |
66 | 20 | ||
67 | |||
68 | ### Build Status | 21 | ### Build Status |
69 | 22 | ||
70 | [![Build Status][1]][2] | 23 | [![Build Status][1]][2] |