cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Walters <>
Subject Re: Cordova BlackBerry WebWorks SDKs (5.0 / 6.0 / 7.0 / 10 / PlayBook)
Date Tue, 15 May 2012 16:22:31 GMT
Yeah, I understand and don't disagree. Just think we are probably at
the point where v1 of PlayBook OS should be deprecated if the stat
that >90% have upgraded to v2 within a month of its release is

If the same holds true for BB 10, and BB 10 is released sometime
around October/November for PlayBook (big assumptions) then support
window is small.

On Tue, May 15, 2012 at 11:00 AM, Filip Maj <> wrote:
> Drew, agree with your views on long-term: it doesn't make sense to put too
> much into Air. That being said, as far as I understand, we won't be able
> to support Playbook v1 and 2 without an Air implementation. Furthermore,
> the SDK or language "convergence" for WebWorks on RIM's end has no ETA.
> This is an unfortunate reality of the BlackBerry landscape at this time.
> We realistically have to support three implementations for an
> indeterminate amount of time if we want full coverage of that platform.
> If this is incorrect, please, Ken/Gord correct me.
> On 5/15/12 6:20 AM, "Drew Walters" <> wrote:
>>Personally, I feel the Air route seems like a short lived dead end and
>>wonder if it is even worth investing more time in. I understand that
>>it can offer a stop gap until a true BB 10 implementation is ready but
>>its hard to be motivated to work on something that is hopefully
>>dead/suboptimal in 6 months time frame.
>>I was hoping that the BB 10 WebWorks SDK would have the custom
>>extension framework ready but that is not the case:
>>However, this doesn't mean work can't be done in the meantime. The
>>native code implementations could still be written and then merged
>>into the framework once it is available. I see this as having more
>>long term value then enhancing the Air implementation.
>>As far as separating the repos...... I would agree it seems to make
>>sense now to separate the repos. However, from an end user
>>perspective, having a single repo allows us to build a distribution
>>where the end user can have a single project and build both the java
>>and Air versions of their application.
>>If we separate into three repos (java, air, c++), what does the
>>distribution look like?  Would there still be a single sample project
>>that is capable of building the different versions or would there be
>>independent build implementations?
>>Also, when we rename, can we drop the "webworks"? Right before the
>>move to Apache we had dropped the "webworks" such that the repo was
>>phonegap-blackberry.  That got lost in the move to Apache though.
>>On Tue, May 15, 2012 at 3:18 AM, Brian LeRoux <> wrote:
>>> Good times. You guys want to try and get the Air repo up before
>>> graduation or wait until after too?
>>> On Tue, May 15, 2012 at 12:43 AM, Michael Brooks
>>> <> wrote:
>>>> Right.
>>>> And just to simplify the transition, we would rather not immediately
>>>> "incubator-cordova-blackberry-webworks" to
>>>> "incubator-cordova-blackberry-java". Instead, we can hold off until
>>>> post-graduation since every repository will need to be renamed
>>>> the "incubator" prefix).
>>>> Michael
>>>> On Mon, May 14, 2012 at 3:35 PM, Filip Maj <> wrote:
>>>>> >The proposed repositories are:
>>>>> >
>>>>> >- cordova-blackberry-webworks
>>>>> >- cordova-blackberry-webworks-air (must be created)
>>>>> >
>>>>> >After Apache graduation, we can rename the repositories to:
>>>>> >
>>>>> >- cordova-blackberry-webworks-java
>>>>> >- cordova-blackberry-webworks-air
>>>>> Just want to quickly add a few more things.
>>>>> Presumably at some point (post-graduation) we will want to add a
>>>>> cordova-blackberry-webworks-qnx (webworks-c++?) repository that would
>>>>> house the WebWorks implementation rocking c++. My understanding
>>>>> the BB10JAM event that the air implementation should keep us covered
>>>>> BB7, BB10 and Playbook platforms for a little while (with the
>>>>> side effect being that air apps running on QNX incur an "overhead" of
>>>>> about 20%).
>>>>> Eventually we'll be able to retire the Air implementation (assuming
>>>>> books get upgraded to QNX), and we can keep the Java implementation
>>>>> for BB5/6/7 legacy support.
>>>>> Phew, what a mess.

View raw message