[guardian-dev] NetCipher Book Chapter, and HTTP Stack Integration

[Mark Murphy]

On Mon, Mar 21, 2016, at 09:39, Hans-Christoph Steiner wrote:
> As for a plan for integrating this into NetCipher, I'd like to start
> with the HttpURLConnection first, especially the SNI stuff.  

Does "the HttpURLConnection" mean you want the StrongConnectionBuilder?
Or are you referring to something else?

> As for OrbotInitializier, ideally that would be merged into OrbotHelper
> somehow.  

I am not aware of any conflicts there. IIRC, OrbotHelper is a basket of
static methods.

> I see you made a StatusCallback interface.  Is there any need
> to have separate Orbot status handling for each HTTP API?

There isn't separate handling for each API.

In my book sample code, the netcipher-hurl module serves double-duty as
the home for HttpURLConnection support and as a "common" module for
things like OrbotInitializer that are needed for all APIs. I didn't
anticipate a need for a "common" module when I started out, then ran
into deadline issues and elected to not try to separate that out. I
apologize for any confusion there.

For formal integration into NetCipher, the following classes from
netcipher-hurl ideally should go into libnetcipher:

- OrbotInitializer
- StatusCallback
- StrongBuilder
- StrongBuilderBase

as those are common to all four of the HTTP API integrations. The
remaining classes are specific to HttpURLConnection and could go in
libnetcipher or a separate artifact/module. The other three integrations
really need to go into separate artifact/modules, simply because they
depend upon third-party libraries (e.g., Volley), and you don't want to
force all NetCipher users to pull in all those dependencies.

BTW, and FWIW, the sample code is now in my book's GitHub repo:

https://github.com/commonsguy/cw-omnibus/tree/master/Internet/HTTPStacks

-- 
Mark Murphy (a Commons Guy)
https://commonsware.com | https://github.com/commonsguy
https://commonsware.com/blog | https://twitter.com/commonsguy