Damian Johnson commited on 2013-03-08 18:00:50
Zeige 1 geänderte Dateien mit 0 Einfügungen und 62 Löschungen.
Last year I proposed a stem counterpart for PathSupport as a project for GSoC. This did not go very well since we really haven't a clue *what* we want from such a project. Since then this has not changed and there's little reason to leave it on the page (even commented out).
... | ... |
@@ -1650,68 +1650,6 @@ meetings around the world.</li> |
1650 | 1650 |
</li> |
1651 | 1651 |
--> |
1652 | 1652 |
|
1653 |
- <!-- |
|
1654 |
- <a id="stemPathsupport"></a> |
|
1655 |
- <li> |
|
1656 |
- <b>Stem PathSupport Capabilities</b> |
|
1657 |
- <br> |
|
1658 |
- Effort Level: <i>High</i> |
|
1659 |
- <br> |
|
1660 |
- Skill Level: <i>Medium</i> |
|
1661 |
- <br> |
|
1662 |
- Likely Mentors: <i>Damian (atagar)</i> |
|
1663 |
- <p><a |
|
1664 |
- href="https://trac.torproject.org/projects/tor/wiki/doc/stem">Stem</a> is a |
|
1665 |
- python controller library for tor. Like it's predecessor, <a |
|
1666 |
- href="#project-torctl">TorCtl</a>, it uses tor's <a |
|
1667 |
- href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt">control |
|
1668 |
- protocol</a> to help developers program against the tor process, enabling |
|
1669 |
- them to build things similar to <a href="#project-vidalia">Vidalia</a> and |
|
1670 |
- <a href="#project-arm">arm</a>.</p> |
|
1671 |
- |
|
1672 |
- <p>While TorCtl provided a fine first draft for this sort of functionality, |
|
1673 |
- it has not proved to be extensible nor maintainable. Stem is a rewrite of |
|
1674 |
- TorCtl with a heavy focus on testing, documentation, and providing a |
|
1675 |
- developer friendly API.</p> |
|
1676 |
- |
|
1677 |
- <p>At the moment stem is still very much incomplete, missing several pieces |
|
1678 |
- of functionality that TorCtl provides. This is a project to fix that by |
|
1679 |
- porting TorCtl's <a |
|
1680 |
- href="https://gitweb.torproject.org/pytorctl.git/blob/HEAD:/PathSupport.py">PathSupport |
|
1681 |
- module</a> to stem, writing tests for it, and migrate a couple clients to |
|
1682 |
- use it.</p> |
|
1683 |
- |
|
1684 |
- <p>PathSupport provides applications with programmatic control over how |
|
1685 |
- tor's circuits are built, for instance letting you exit from particular |
|
1686 |
- relays. This is used by projects like <a href="#project-torbel">TorBEL</a>, |
|
1687 |
- <a href="#project-torflow">the Bandwidth Scanners, and SoaT</a>.</p> |
|
1688 |
- |
|
1689 |
- <p>This project can be broken into three parts...</p> |
|
1690 |
- |
|
1691 |
- <ol style="list-style-type: decimal"> |
|
1692 |
- <li><p>Look at PathSupport's clients to figure out how it is used and |
|
1693 |
- come up with the API that we will use for stem. Note that the goal if |
|
1694 |
- this project is <b>not</b> to simply copy PathSupport, but to make it |
|
1695 |
- better. This task would ideally be done as part of writing the GSoC |
|
1696 |
- application.</p></li> |
|
1697 |
- <li><p>Implement the PathSupport counterpart for stem. This should be |
|
1698 |
- done in an incremental fashion, writing the feature, tests, and going |
|
1699 |
- through a code review before moving on. I'll be pretty anal about making |
|
1700 |
- it as good as we can during these code reviews so plan for this to take a |
|
1701 |
- while. ;)</p></li> |
|
1702 |
- <li><p>The real test of the API that you've developed will come when we |
|
1703 |
- use it in some real applications. Try to migrate a TorCtl client or two |
|
1704 |
- to stem, filling in functionality that we're missing and improving our |
|
1705 |
- API as we discover issues. A particularly good client to start with would |
|
1706 |
- be TorBEL.</p></li> |
|
1707 |
- </ol> |
|
1708 |
- |
|
1709 |
- <p><b> |
|
1710 |
- Upon reflection this is not an especially good project for this year's GSoC. You are still perfectly wecome to apply for this project, but <a href="https://trac.torproject.org/projects/tor/wiki/doc/stem">other stem related tasks</a> such as implementing a general controller, descriptor fetching, and client migrations would be better. For the discussion that lead to this see <a href="http://archives.seul.org/or/dev/Apr-2012/msg00006.html">this thread</a>. |
|
1711 |
- </b></p> |
|
1712 |
- </li> |
|
1713 |
- --> |
|
1714 |
- |
|
1715 | 1653 |
<a id="stemUsability"></a> |
1716 | 1654 |
<li> |
1717 | 1655 |
<b>Stem Usability and Porting</b> |
1718 | 1656 |