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 /BEP.md | |
| parent | 944b8bfb6959944c607a2f9bd7af42fd654e5d32 (diff) | |
~ Move beps status to separate file.
Diffstat (limited to 'BEP.md')
| -rw-r--r-- | BEP.md | 45 |
1 files changed, 45 insertions, 0 deletions
| @@ -0,0 +1,45 @@ | |||
| 1 | The protocol has many extensions(more precisely enchancements, but | ||
| 2 | we'll use that word) and it's seems like no one will want to use just | ||
| 3 | core protocol, at least I'm not. Any modern application that uses | ||
| 4 | bittorrent protocol in any way will use some subset of extensions. | ||
| 5 | Thus it's reasonable to implement at least some part of widely used | ||
| 6 | extensions here, so we could provide nice high level API and well | ||
| 7 | integrated interface. | ||
| 8 | |||
| 9 | This section should keep track current state of package in respect of | ||
| 10 | BEP's. Please _don't_ use this list as issue or bug tracker or TODO | ||
| 11 | list or anything else: when in doubt don't change the table. | ||
| 12 | |||
| 13 | In order to keep table compact we describe table layout at first: | ||
| 14 | |||
| 15 | * **BEP #** — Just number of enchancement. | ||
| 16 | * **Title** — Full official enchancement name. | ||
| 17 | * **Modules** — modules that _directly_ relates to the BEP. This is where | ||
| 18 | BEP implemented, where we should look for the BEP. If a module has | ||
| 19 | only changes due to integration with the BEP then it _should not_ be | ||
| 20 | listed in the **Modules** list. | ||
| 21 | * **Status** — is the current state of the BEP. Status lifecycle has the | ||
| 22 | only way: Want -> Implemented -> Tested -> Integrated -> Done. You | ||
| 23 | might use (A -> B) to indicate intermediate steps. Note that | ||
| 24 | implemented _doesn't_ means that BEP is ready to use, it _will_ be | ||
| 25 | ready to use only after it pass Tested, Integrated and finally | ||
| 26 | becomes Done. | ||
| 27 | |||
| 28 | We should try keep table in order of priority, so first BEPs should be | ||
| 29 | are most important and last BEPs are least important. (but important | ||
| 30 | too) | ||
| 31 | |||
| 32 | | BEP # | Title | Modules | Status | ||
| 33 | |:-----:|:------------------------------------------:|:------------------------------------|:----------- | ||
| 34 | | 3 | The BitTorrent Protocol Specification | Data.Torrent | Implemented | ||
| 35 | | | | Network.BitTorrent.Peer | | ||
| 36 | | | | Network.BitTorrent.PeerWire | | ||
| 37 | | | | Network.BitTorrent.Tracker | | ||
| 38 | | 4 | Known Number Allocations | Network.BitTorrent.Extension | Want -> Implemented | ||
| 39 | | 20 | Peer ID Conventions | Network.BitTorrent.Peer.ID | Want -> Implemented | ||
| 40 | | | | Network.BitTorrent.Peer.ClientInfo | | ||
| 41 | | 9 | Extension for Peers to Send Metadata Files | | Want | ||
| 42 | | 23 | Tracker Return Compact Peer Lists | Network.BitTorrent.Tracker.Protocol | Implemented | ||
| 43 | | | | Network.BitTorrent.PeerWire.Message | | ||
| 44 | | 5 | DHT | | Want | ||
| 45 | | 6 | Fast Extension | Network.BitTorrent.PeerWire.Message | Want -> Implemented | ||