On 4/2/13 12:09 AM, Nick Mathewson wrote: > > My preferred approach for applications that want to include their own > Tor would be to have a library (perhaps based on Torsocks) that > handles making connections over Tor, plus maybe another library that > would find a running Tor or launch one as needed. That way we wouldn't > have a huge pile of apps all stuck downloading their own directory > information, and we wouldn't wind up with a bunch of forked Tor > versions all diverging independently. > > Nonetheless, people keep wanting to do it the way you suggest, and > it's free software, so do what you like.
While i understand that you do not like this solution we should also acknowledge that there are several condition where "running an independent process" is just not an option and, not having a Tor as a library, represent a limitation. By design it's required/better to have tor built as a part of the application in the following conditions for example: - if you need to deploy a "Single executable" - if, for security reason, you need a unique application update system - if your application can't startup other applications (for example on App Stores) - If your application have strict signing requirements (for example on App Stores) - if you need a forensically proof application (not writing file around, not being able to use kernel-level disk encryption) - If you can't open listening port on the specific system due to permissions - if you need to do filesystem i/o only on a single application's database file (like a sqlite) If we would have Tor also workable as a library, IMHO we would have a clean-by-design-from-software-engineering-point-of-view way to use Tor. Fabio _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev