+1 unbundle. The reason we added it in was that it fixes issues with Android's built-in networking stack. It was added pre-plugin-breakout, and was never broken out into its own plugin.
The good news is that I think it'll be quite straight-forward to extract it out. We don't expose OkHttp interfaces anywhere, and instead exposed it through CordovaResourceApi via createHttpConnection() (which returns a HttpURLConnection, not an OkHttp interface). The grey area is whether we'd want the FileTransfer plugin to depend on OkHttp, or whether we just have FileTransfer be flakey on pre-KitKat devices if devs don't choose to add the plugin. I think I'd be in the camp of adding it by default, but then allow it to be removed via "plugin rm". Our tools don's support that right now though. On Tue, Sep 30, 2014 at 8:51 AM, Marcel Kinard <[email protected]> wrote: > I agree it would be cleaner to not embed okhttp in Cordova. > > If it is removed, what do you see as the user experience? Does the CLI > automatically download the okhttpd jar from square's github? Or do we > expect the user to do that manually and drop it in a lib folder? > > Would it be possible to have the Apache httpd client take the place of > okhttp, or are there okhttp-specific functions being used? > > On Sep 29, 2014, at 5:16 PM, Joe Bowser <[email protected]> wrote: > > > Hey > > > > Can we unbundle okhttp without breaking Cordova? I think that our > bundling > > has become a serious problem, and we should find a way to abstract the > > dependency away somehow into a plugin and should do this in 4.0.x. > > > > Ian, anyone else who knows what's going on with File/URIs? What's your > > thoughts on this? > > > > Joe > >
