[tor-commits] [tech-reports/master] Add Sathya's comments from tor-dev@.

[karsten@xxxxxxxxxxxxxx]

commit 6df54da6f97d3c3127f23b066f1596e9ff62558e
Author: Karsten Loesing <karsten.loesing@xxxxxxx>
Date:   Tue Sep 24 15:10:04 2013 +0200

    Add Sathya's comments from tor-dev@.
---
 2013/torperf2/torperf2.tex |   39 ++++++++++++++++++++++++++++++---------
 1 file changed, 30 insertions(+), 9 deletions(-)

diff --git a/2013/torperf2/torperf2.tex b/2013/torperf2/torperf2.tex
index d67bd62..b8f2e71 100644
--- a/2013/torperf2/torperf2.tex
+++ b/2013/torperf2/torperf2.tex
@@ -121,13 +121,27 @@ What's not easily possible with this approach is to configure client and
 server to run on different hosts.  Is there an experiment where this
 might be useful?
 
-\subsubsection{Experiment extensibility considerations}
-
-It should be easy for a user to implement or install an experiment that isn't
-bundled with the core distribution. Ideally, installing an experiment should be as
-simple as unzipping a folder or config file into an experiments folder.
-Optimally, the Torperf service would detect the new experiment and schedule
-it as soon as practical without additional user intervention.
+% Commented out Kevin's text on 2013-09-24:
+% \subsubsection{Experiment extensibility considerations}
+%
+% It should be easy for a user to implement or install an experiment that isn't
+% bundled with the core distribution. Ideally, installing an experiment should be as
+% simple as unzipping a folder or config file into an experiments folder.
+% Optimally, the Torperf service would detect the new experiment and schedule
+% it as soon as practical without additional user intervention.
+% Sathya on tor-dev@:
+% "I don't understand how this will work when users just apt-get install
+% torperf. Ideally if someone writes a good experiment, they should send
+% the patches upstream and get it merged, and then we update torperf to
+% include those tests and then the users just update torperf with their
+% package managers."
+% Karsten on tor-dev@:
+% "I don't feel strongly.  I'd prefer a design that makes it easy to add
+% new experiments, but I'm fine with an approach that requires merging
+% patches.  We can always add the functionality to drop something in a
+% directory and make Torperf magically detect and run the new experiment,
+% but that can happen later.  Maybe we shouldn't let that distract us from
+% getting the first version done.  I commented out this section."
 
 % Commented out Kevin's text by Karsten on 2013-09-18:
 % For implementing, this will require a clearly defined interface for developers
@@ -179,6 +193,12 @@ signature of new tor versions as they are released. The user could specify
 if they plan to test stable, beta or alpha versions of tor with their
 Torperf instance.
 
+This requirement should be implemented in three phases: 1) Torperf uses
+the default tor binary that comes with the operating system; 2) Torperf
+accepts the path to a tor binary that was previously built by the user;
+3) Torperf accepts that path to a Git tag or tor source directory and
+downloads, verifies, and builds a tor binary itself.
+
 \subsubsection{User-defined third-party software version or binary}
 
 Similar to the previous requirement, it should be easy to specify custom
@@ -217,7 +237,9 @@ requests.%
 Deciding which data to store should be the responsibility of whoever
 designs a Torperf experiment, though formats should be somewhat uniform
 between experiments.
-A possible results data format could be based on JSON,%
+Torperf should store its results in a format that is widely used and
+already has libraries (like JSON), so that other applications can use
+the results and build on it.%
 \footnote{In particular, we could use a de-facto standard like the HAR
 (HTTP Archive) format to store measurements results.
 Advantages are that such a format is widely used and that there are a lot
@@ -227,7 +249,6 @@ not relevant to us, and that we'd have to add tor-specific data fields to
 the format which wouldn't be processed by existing tools.
 Note that we could use such a format only for request data, not for
 tor-specific data like building circuits and attaching streams.}
-but other data formats are plausible, too.
 
 \subsubsection{Results web interface}
 



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits