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

Ondrej Mikle ondrej.mikle at gmail.com
Mon Jul 16 00:15:55 UTC 2012


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

It's a middleware platform for building exactly this kind of distributed
services. Many supported languages (C++/Python/Ruby/Java/...) and OSes
(Mac/Lin/Win/Android/...)

It might seem difficult or "enterprisey", but it's simple for simple things
(like RPC) and complicated only when you want complicated things (have look at
demo programs).

It can optionally use TLS, interface definition for RPC and structures is
written only once (each language binding then loads it and maps it to native
object of its own as "usual" method calls or attributes).

Advanced features include asynchronous calls, at-most-once semantics (it can
retry RPC call for methods that are marked "idempotent", i.e. whose multiple
invocation is same as one invocation), persistence via Ice Freeze (might work
for the file storage, not sure how big are your files, internally it's
implemented on top of BerkeleyDB), forward/backward compatibility among versions
of your API (up to a limit)...

Disadvantages:

- you'll have one more library blob to carry around (though Ice is in default
Debian/Ubuntu repos and official RPM repos are available; core lib is about 3MB
large)
- GPL licensed (might conflict with other libraries' licenses)
- certainly not as simple as GET/POST request

It's probably the most sane "generic" middleware/RPC platform I've seen and I've
worked with a bunch of them - RESTful APIs, variants of XML-RPC, monsters like
webservices/SOAP and CORBA (it always starts with "I just need this simple
thing" and ends with "how do I hack this onto the existing API so that old
clients end existing infrastructure won't break?")

Ondrej

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20120716/f53acad5/attachment.pgp>


More information about the tor-dev mailing list