[tor-dev] [OONI] Designing the OONI Backend (OONIB). RESTful API vs rsynch

Ondrej Mikle ondrej.mikle at gmail.com
Thu Jul 19 00:17:27 UTC 2012

Hash: SHA1

On 07/18/2012 04:46 PM, Arturo Filastò wrote:
> On 7/16/12 2:15 AM, Ondrej Mikle wrote:
>> On 07/15/2012 02:56 PM, Arturo Filastò wrote:
>>> I would like to follow up on the discussion we had in Florence on some 
>>> design choices behind OONIB.
>>> In particular the most controversy was around using HTTP or rsync.
>> [...]
>>> # What properties we would like it to have note: these are not
>>> ordered.
>>> * Efficient even over high latency networks.
>>> * Ease of integration for third party developers.
>>> * Expandable to support requirements of new tests we develop.
>>> * Anonymous
>>> * Secure
>> Even though you will probably not end up using this, it may be a good
>> idea to know that it exists:
>> ZeroC Ice - http://www.zeroc.com/ice.html
> There are a bunch of very fancy and nice libraries out there to do RPC
> like things that support a variety of languages.
> Moreover by looking at how the reporting systems of other network 
> measurements tools worked [5] we found that almost all of them used an HTTP
> API to collect reports [6][7][8][9]. I see this as an indication that such
> a strategy is the best practice.

Since it's already implemented, it's reasonable to keep it that way.

> For the time being we should go for something simple like this and once we
> encounter major scalability/performance bottlenecks we can quantify them
> and figure out what the best path to a solution may be.

Sure (though this transition is always PITA once it is necessary).

> If you were the developer of a censorship detection tool would you like to
> have to report to anything that is not a RESTful HTTPs API?

Hmm, for some reason I remembered there was some debate on stateful
requirements on the API but can't seem to find it.

Version: GnuPG v2.0.14 (GNU/Linux)


More information about the tor-dev mailing list