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

[Isis <isis@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon 16 Jul 2012 at 02:15, thus spake Ondrej Mikle:
> On 07/15/2012 02:56 PM, Arturo Filastà wrote:
> > 
> > # 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

I took a breif look at it and it does actually look quite nice...

I'm about half convinced, but am also rather inexperienced with designing
distributed, secure, anonymous, multi-platform, scalable RPC systems. ugh...I
think that string of buzzwords just made me puke in my mouth a little bit.

> 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).

Oh man. It's not Twisted, that's for sure. :)

Though, it seems that much of Ice is redundant if we are already packaging
Twisted. Perhaps we could use their code as reference, and just write out the
methods we need in Twisted to avoid the extra dependency?

> 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)...
 
Becoming more convinced. Do you know off the top of your head which protocol
it uses? HTTP also, I would assume?

Side note: What are we going to do for countries which block/monitor/MITM SSL
connections? If I'm not mistaken, hasn't it been the case that these places
have still allowed ssh? Should we have some sort of append-only scp-like
fallback? Does Ice have that?

> 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)

Ah, yes, but if you use just the Python libraries, it looks like the size
ranges from 600kb for Debian to uh...actually I can't find anywhere which has
just the Python libraries for Windows. The largest size for a Linux distro
does look to be about 3MB, you're right.

> - 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?")


<(A)3
isis agora lovecruft
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQBcZBAAoJEKOttnos24s1clgQALtU3XKp1DnU8eqDsi3xFuo7
FpzR4M9ZEcoMBBbEyP6999TynZTMbFT5ISwR8u0U/9rlTK4fJw5CxuyLwk93/W+K
zS9Cv1wMVhXKefpIhl+6LHa1oeSzAnNThzAZtKaA2eWQgaTC21fCn7CSa1RCX3NT
v8B9cEiZtnQwXGl83b0zUmUwYy3f9X62Lmag2DZNzOM4QKtyPDeqQQ/SDPvttzl2
k0ZuaIvSFXjR/WhuL18mtzbL+azGeMz1Cs8mE+vI7UuiA353DAjiC9OhZAd6k9ut
eHVzU/eaa9v5TMIyuf70eoZRF7wKqY2Z+0L6hAxaT6p4ZRrdOWCw7O95qdmoBQWT
IttjTLV3y+msUp+Dsdy1gn6rCDTRPeRX5m0+5nY9eX4lDCyGdYf50mRKJ6DlMK3j
waZVJqJDtOf5tIhZBiBkDRWb4N669KCoca9TNtwCSiBaJgTorcTenGaW9Z73L3MA
6QlVfPj3GWqCXGqIoo9jaZkHI5V3zFd7he4+SPenHJyuWIFkqST867M5Zg6/1oJZ
A0Wi3KFgSdaAOB5M9KA49X6BlTeTyE3BBV+DTydEL0MsQ2ZWvwAxh/FchFw65Qm0
9tTyzi0ZSzDczXQGvz2hneJ1XQoxWX1NPcrWwZldOKrtb6wHbzoNz3gtY8G0FEF1
l+41r2JrBkQQTHcxlSEd
=ygcX
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev