incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: [Android] Can we get rid of the Callback Server/Hanging GET now?
Date Tue, 18 Sep 2012 18:23:16 GMT
I believe that was the general consensus, yes. Since the bridge workings
are purely internal and not user-facing we should be able to switch
between them (as long as tests pass) without warning.

Deprecating supported platforms is another case, IMO. We should give users
enough time to be able to adjust accordingly. Maybe slate it for 2.5 or
so? Can we also dump some kind of warning/deprecation message on 2.1 and
3.x devices?

Finally, leading up to the release that removes support for those devices,
we should tweet/blog about dropping support for those Android platforms.

On 9/18/12 11:19 AM, "Joe Bowser" <> wrote:

>OK, so if we keep the Callback Server as an option, but change the
>default, would that be fine for the deprecation policy?
>On Tue, Sep 18, 2012 at 11:14 AM, Filip Maj <> wrote:
>> I would like us to follow our current deprecation policy: 6 months, or
>> point releases.
>> This way we can make noise about it leading up to it for our users.
>> blog posts, etc.
>> On 9/18/12 11:12 AM, "Joe Bowser" <> wrote:
>>>OK, This sounds like a proposal.  Do we need to do a vote, or should
>>>we just add a JIRA issue to 2.2?
>>>On Wed, Sep 12, 2012 at 5:25 PM, Andrew Grieve <>
>>>> ONLINE_EVENTS and JS_OBJECT are the fastest and have no bugs that I've
>>>> found. As soon as 2.1 ships, let's make the switch. I don't think devs
>>>> should need to know about the bridge modes unless there becomes a
>>>>reason to
>>>> expose this to them.
>>>> With several other options other than callback server, I think we
>>>> get rid of it since it's a fair amount of code and complexity.
>>>> On Wed, Sep 12, 2012 at 3:41 PM, Filip Maj <> wrote:
>>>>> I would be in favor of dropping a deprecation-like notice and
>>>>> users about the differences.
>>>>> I would change the default bridge mode to the events one, say in 2.2
>>>>> 2.3. Then like 2.5 remove the callback server if we've gone through a
>>>>> couple release with no issues with the new bridge mode.
>>>>> My $0.02.
>>>>> On 9/12/12 12:38 PM, "Joe Bowser" <> wrote:
>>>>> >Hey
>>>>> >
>>>>> >In 2.1.0, we currently have the ability to use multiple bridges
>>>>> >to Andrew's work.  However, we currently still have a series of
>>>>> >related to the fact that on Android 4.x, the routing tables decided
>>>>> >take a vacation and never come back when there's no Internet
>>>>> >connection.  This means that the bridge freezes up and never comes
>>>>> >back.  This wouldn't be an issue if this wasn't our default bridge
>>>>> >method.  In addition to this, a large amount of memory usage on
>>>>> >Android is also taken up with this callback server.  So, I think
>>>>> >should take this thing out behind the shed and put it out of its
>>>>> >misery.
>>>>> >
>>>>> >As far as what should replace it, I'm for the overriding of the
>>>>> >event for replacing it, since it performs faster than the others,
>>>>> >actually works across all the versions of Android based on what I've
>>>>> >tested so far (2.2.2 to 4.1.1).
>>>>> >
>>>>> >Any thoughts or reasons why this method should survive?
>>>>> >
>>>>> >Joe

View raw message