cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: [Android] Unbundling okhttp
Date Wed, 31 Dec 2014 04:15:14 GMT
Just committed the removal of this.

https://issues.apache.org/jira/browse/CB-6630
https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=c6b171b

Note that there is *no* API change to org.apache.cordova.* classes, but it
still could be considered a breaking change since any plugin that assumed
the OkHttp classes are included would be wrong (though, I'm not aware of
any such plugins).

I've created a plugin in labs that shows how to re-add OkHttp via gradle:
https://github.com/apache/cordova-plugins/tree/master/android-okhttp


On Tue, Sep 30, 2014 at 4:43 PM, Andrew Grieve <agrieve@chromium.org> wrote:

>
>
> On Tue, Sep 30, 2014 at 12:08 PM, Joe Bowser <bowserj@gmail.com> wrote:
>
>> On Tue, Sep 30, 2014 at 8:52 AM, Andrew Grieve <agrieve@chromium.org>
>> wrote:
>>
>> > +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.
>> >
>> >
>> Because CordovaResourceApi is a core API.
>>
> Sorry, I was referring to OkHttp here, not CordovaResourceApi.
>
>
>
>>
>>
>> > 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).
>> >
>> >
>> How many plugins depend on this functionality?
>>
> No idea. File Transfer does. My point though is that we can remove OkHttp
> without changing the signature of this function. We can just return the
> system default HTTPURLConnection.
>
>
>>
>>
>> > 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.
>> >
>>
>> I don't think this is a grey area.  We could move this in the plugin, but
>> this is an API change.  Can you create a feature branch off 4.0.x with
>> this?
>>
> Definitely don't want to bundle it with FileTransfer in case another
> plugin also wants to use OkHttp. We'd need it to be its own plugin.
>
> This work is unfortunately not on my radar to work on in the near term.
>
>
>
>>
>>
>> >
>> >
>> >
>> >
>> > On Tue, Sep 30, 2014 at 8:51 AM, Marcel Kinard <cmarcelk@gmail.com>
>> 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 <bowserj@gmail.com> 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
>> > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message