[Android] Can we get rid of the Callback Server/Hanging GET now?

[Joe Bowser <bo...@gmail.com>]

Hey

In 2.1.0, we currently have the ability to use multiple bridges thanks
to Andrew's work.  However, we currently still have a series of issues
related to the fact that on Android 4.x, the routing tables decided to
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 we
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 online
event for replacing it, since it performs faster than the others, and
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

Re: [Android] Can we get rid of the Callback Server/Hanging GET now?

[Joe Bowser <bo...@gmail.com>]

OK, I'll create a ticket for it.

On Tue, Sep 18, 2012 at 11:23 AM, Filip Maj <fi...@adobe.com> wrote:
> 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" <bo...@gmail.com> 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 <fi...@adobe.com> wrote:
>>> I would like us to follow our current deprecation policy: 6 months, or
>>>5-6
>>> point releases.
>>>
>>> This way we can make noise about it leading up to it for our users.
>>> Phonegap.com blog posts, etc.
>>>
>>> On 9/18/12 11:12 AM, "Joe Bowser" <bo...@gmail.com> 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 <ag...@chromium.org>
>>>>wrote:
>>>>> 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
>>>>>should
>>>>> 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 <fi...@adobe.com> wrote:
>>>>>
>>>>>> I would be in favor of dropping a deprecation-like notice and
>>>>>>educating
>>>>>> users about the differences.
>>>>>>
>>>>>> I would change the default bridge mode to the events one, say in 2.2
>>>>>>or
>>>>>> 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" <bo...@gmail.com> wrote:
>>>>>>
>>>>>> >Hey
>>>>>> >
>>>>>> >In 2.1.0, we currently have the ability to use multiple bridges
>>>>>>thanks
>>>>>> >to Andrew's work.  However, we currently still have a series of
>>>>>>issues
>>>>>> >related to the fact that on Android 4.x, the routing tables decided
>>>>>>to
>>>>>> >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 we
>>>>>> >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
>>>>>>online
>>>>>> >event for replacing it, since it performs faster than the others,
>>>>>>and
>>>>>> >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
>>>>>>
>>>>>>
>>>
>

Re: [Android] Can we get rid of the Callback Server/Hanging GET now?

[Filip Maj <fi...@adobe.com>]

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" <bo...@gmail.com> 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 <fi...@adobe.com> wrote:
>> I would like us to follow our current deprecation policy: 6 months, or
>>5-6
>> point releases.
>>
>> This way we can make noise about it leading up to it for our users.
>> Phonegap.com blog posts, etc.
>>
>> On 9/18/12 11:12 AM, "Joe Bowser" <bo...@gmail.com> 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 <ag...@chromium.org>
>>>wrote:
>>>> 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
>>>>should
>>>> 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 <fi...@adobe.com> wrote:
>>>>
>>>>> I would be in favor of dropping a deprecation-like notice and
>>>>>educating
>>>>> users about the differences.
>>>>>
>>>>> I would change the default bridge mode to the events one, say in 2.2
>>>>>or
>>>>> 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" <bo...@gmail.com> wrote:
>>>>>
>>>>> >Hey
>>>>> >
>>>>> >In 2.1.0, we currently have the ability to use multiple bridges
>>>>>thanks
>>>>> >to Andrew's work.  However, we currently still have a series of
>>>>>issues
>>>>> >related to the fact that on Android 4.x, the routing tables decided
>>>>>to
>>>>> >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 we
>>>>> >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
>>>>>online
>>>>> >event for replacing it, since it performs faster than the others,
>>>>>and
>>>>> >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
>>>>>
>>>>>
>>

Re: [Android] Can we get rid of the Callback Server/Hanging GET now?

[Joe Bowser <bo...@gmail.com>]

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 <fi...@adobe.com> wrote:
> I would like us to follow our current deprecation policy: 6 months, or 5-6
> point releases.
>
> This way we can make noise about it leading up to it for our users.
> Phonegap.com blog posts, etc.
>
> On 9/18/12 11:12 AM, "Joe Bowser" <bo...@gmail.com> 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 <ag...@chromium.org>
>>wrote:
>>> 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 should
>>> 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 <fi...@adobe.com> wrote:
>>>
>>>> I would be in favor of dropping a deprecation-like notice and educating
>>>> users about the differences.
>>>>
>>>> I would change the default bridge mode to the events one, say in 2.2 or
>>>> 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" <bo...@gmail.com> wrote:
>>>>
>>>> >Hey
>>>> >
>>>> >In 2.1.0, we currently have the ability to use multiple bridges thanks
>>>> >to Andrew's work.  However, we currently still have a series of issues
>>>> >related to the fact that on Android 4.x, the routing tables decided to
>>>> >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 we
>>>> >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 online
>>>> >event for replacing it, since it performs faster than the others, and
>>>> >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
>>>>
>>>>
>

Re: [Android] Can we get rid of the Callback Server/Hanging GET now?

[Filip Maj <fi...@adobe.com>]

Yes, we document upgrade guides for each release now in our docs [1].

I like the idea of putting these types of future / deprecation decisions
into the guides as well.

On 9/18/12 12:51 PM, "Marcel Kinard" <cm...@gmail.com> wrote:

>After it gets deprecated, is it consistent practice to document Cordova
>migration tasks for app developers in someplace like
>docs/LANG/VERSION/guide/upgrading/PLATFORM ?
>
>And maybe in that same file could be an extra section identifying items
>which are scheduled for future deprecation so app developers could get
>an early migration jump on them or at least be aware they are coming.
>
>-- Marcel Kinard
>
>On 9/18/2012 2:14 PM, Filip Maj wrote:
>> I would like us to follow our current deprecation policy: 6 months, or
>>5-6
>> point releases.
>>
>> This way we can make noise about it leading up to it for our users.
>> Phonegap.com blog posts, etc.
>>
>> On 9/18/12 11:12 AM, "Joe Bowser" <bo...@gmail.com> 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 <ag...@chromium.org>
>>> wrote:
>>>> 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
>>>>should
>>>> 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 <fi...@adobe.com> wrote:
>>>>
>>>>> I would be in favor of dropping a deprecation-like notice and
>>>>>educating
>>>>> users about the differences.
>>>>>
>>>>> I would change the default bridge mode to the events one, say in 2.2
>>>>>or
>>>>> 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" <bo...@gmail.com> wrote:
>>>>>
>>>>>> Hey
>>>>>>
>>>>>> In 2.1.0, we currently have the ability to use multiple bridges
>>>>>>thanks
>>>>>> to Andrew's work.  However, we currently still have a series of
>>>>>>issues
>>>>>> related to the fact that on Android 4.x, the routing tables decided
>>>>>>to
>>>>>> 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 we
>>>>>> 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
>>>>>>online
>>>>>> event for replacing it, since it performs faster than the others,
>>>>>>and
>>>>>> 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
>>>>>
>

Re: [Android] Can we get rid of the Callback Server/Hanging GET now?

[Marcel Kinard <cm...@gmail.com>]

After it gets deprecated, is it consistent practice to document Cordova 
migration tasks for app developers in someplace like 
docs/LANG/VERSION/guide/upgrading/PLATFORM ?

And maybe in that same file could be an extra section identifying items 
which are scheduled for future deprecation so app developers could get 
an early migration jump on them or at least be aware they are coming.

-- Marcel Kinard

On 9/18/2012 2:14 PM, Filip Maj wrote:
> I would like us to follow our current deprecation policy: 6 months, or 5-6
> point releases.
>
> This way we can make noise about it leading up to it for our users.
> Phonegap.com blog posts, etc.
>
> On 9/18/12 11:12 AM, "Joe Bowser" <bo...@gmail.com> 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 <ag...@chromium.org>
>> wrote:
>>> 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 should
>>> 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 <fi...@adobe.com> wrote:
>>>
>>>> I would be in favor of dropping a deprecation-like notice and educating
>>>> users about the differences.
>>>>
>>>> I would change the default bridge mode to the events one, say in 2.2 or
>>>> 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" <bo...@gmail.com> wrote:
>>>>
>>>>> Hey
>>>>>
>>>>> In 2.1.0, we currently have the ability to use multiple bridges thanks
>>>>> to Andrew's work.  However, we currently still have a series of issues
>>>>> related to the fact that on Android 4.x, the routing tables decided to
>>>>> 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 we
>>>>> 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 online
>>>>> event for replacing it, since it performs faster than the others, and
>>>>> 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
>>>>

Re: [Android] Can we get rid of the Callback Server/Hanging GET now?

[Filip Maj <fi...@adobe.com>]

I would like us to follow our current deprecation policy: 6 months, or 5-6
point releases.

This way we can make noise about it leading up to it for our users.
Phonegap.com blog posts, etc.

On 9/18/12 11:12 AM, "Joe Bowser" <bo...@gmail.com> 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 <ag...@chromium.org>
>wrote:
>> 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 should
>> 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 <fi...@adobe.com> wrote:
>>
>>> I would be in favor of dropping a deprecation-like notice and educating
>>> users about the differences.
>>>
>>> I would change the default bridge mode to the events one, say in 2.2 or
>>> 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" <bo...@gmail.com> wrote:
>>>
>>> >Hey
>>> >
>>> >In 2.1.0, we currently have the ability to use multiple bridges thanks
>>> >to Andrew's work.  However, we currently still have a series of issues
>>> >related to the fact that on Android 4.x, the routing tables decided to
>>> >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 we
>>> >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 online
>>> >event for replacing it, since it performs faster than the others, and
>>> >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
>>>
>>>

Re: [Android] Can we get rid of the Callback Server/Hanging GET now?

[Joe Bowser <bo...@gmail.com>]

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 <ag...@chromium.org> wrote:
> 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 should
> 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 <fi...@adobe.com> wrote:
>
>> I would be in favor of dropping a deprecation-like notice and educating
>> users about the differences.
>>
>> I would change the default bridge mode to the events one, say in 2.2 or
>> 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" <bo...@gmail.com> wrote:
>>
>> >Hey
>> >
>> >In 2.1.0, we currently have the ability to use multiple bridges thanks
>> >to Andrew's work.  However, we currently still have a series of issues
>> >related to the fact that on Android 4.x, the routing tables decided to
>> >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 we
>> >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 online
>> >event for replacing it, since it performs faster than the others, and
>> >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
>>
>>

Re: [Android] Can we get rid of the Callback Server/Hanging GET now?

[Andrew Grieve <ag...@chromium.org>]

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 should
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 <fi...@adobe.com> wrote:

> I would be in favor of dropping a deprecation-like notice and educating
> users about the differences.
>
> I would change the default bridge mode to the events one, say in 2.2 or
> 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" <bo...@gmail.com> wrote:
>
> >Hey
> >
> >In 2.1.0, we currently have the ability to use multiple bridges thanks
> >to Andrew's work.  However, we currently still have a series of issues
> >related to the fact that on Android 4.x, the routing tables decided to
> >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 we
> >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 online
> >event for replacing it, since it performs faster than the others, and
> >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
>
>

Re: [Android] Can we get rid of the Callback Server/Hanging GET now?

[Filip Maj <fi...@adobe.com>]

I would be in favor of dropping a deprecation-like notice and educating
users about the differences.

I would change the default bridge mode to the events one, say in 2.2 or
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" <bo...@gmail.com> wrote:

>Hey
>
>In 2.1.0, we currently have the ability to use multiple bridges thanks
>to Andrew's work.  However, we currently still have a series of issues
>related to the fact that on Android 4.x, the routing tables decided to
>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 we
>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 online
>event for replacing it, since it performs faster than the others, and
>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