incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Walters <deedu...@gmail.com>
Subject Re: Cordova BlackBerry WebWorks SDKs (5.0 / 6.0 / 7.0 / 10 / PlayBook)
Date Tue, 15 May 2012 19:24:34 GMT
>> 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?
>
> This is a point that we should discuss more. Regardless of how the
> repositories / distributions are structured, the user will need to be
> educated on which binary supports which BlackBerry OS. Also, regardless of
> structure, each implementation (java, air, c++) will use a different CLI
> build implementation. Currently, we've duct-taped Java and Air under one
> ANT file, but even that is a stretch and user must still configure their
> system appropriately. What are the advantages to keeping a single
> repository? Having a single repository does not mean we need to share the
> ANT script (I'd prefer to not) and the README can help educate users on
> which SDK targets which OS.

If we were to restructure the java implementation how I laid out in my
investigation of making everything pluggable, I think it would
mitigate some of the issues since it removes platform specific code
(native and js) from the project. Assuming the Air and QNX
implementations could also be implemented using the same pattern, then
after installing Cordova into the respective WebWorks SDK(s) the end
user could just use the WebWorks provided packager to build their
project.

Now, as a value add, we could continue to provide some build
automation tools, but I'm beginning to think that those would live
outside the project and be common across all Cordova supported
platforms.

On Tue, May 15, 2012 at 12:41 PM, Michael Brooks
<michael@michaelbrooks.ca> wrote:
> Ken, thanks for clarifying the RIM perspective! It's truly awesome to be
> able to talk directly with a platform vendor.
>
> It sounds like we're getting close to a conclusion!
>
>
>> 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?
>
>
> This is a point that we should discuss more. Regardless of how the
> repositories / distributions are structured, the user will need to be
> educated on which binary supports which BlackBerry OS. Also, regardless of
> structure, each implementation (java, air, c++) will use a different CLI
> build implementation. Currently, we've duct-taped Java and Air under one
> ANT file, but even that is a stretch and user must still configure their
> system appropriately. What are the advantages to keeping a single
> repository? Having a single repository does not mean we need to share the
> ANT script (I'd prefer to not) and the README can help educate users on
> which SDK targets which OS.
>
> 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.
>
>
> Well, "cordova-blackberry-webworks-java" is more accurate than
> "cordova-blackberry-java", which implies the Java JDK not the WebWorks Java
> SDK. However, since Cordova is intending to use the WebWorks implementation
> for all BlackBerry platforms, I'm fine shortening the repository names to
> "cordova-blackberry-java", "cordova-blackberry-air",
> "cordova-blackberry-qnx".
>
> Michael
>
> On Tue, May 15, 2012 at 10:06 AM, <gtanner@gmail.com> wrote:
>
>> Yup :)
>>
>> I am on it.
>> I don't think this is going to be as bad as we all think, esp with
>> cordovaJS.
>>
>> I am imagining a good portion of the API surface to look the same for each
>> of the webworks platforms.
>>
>>
>> Sent on the TELUS Mobility network with BlackBerry
>>
>> -----Original Message-----
>> From: Filip Maj <fil@adobe.com>
>> Date: Tue, 15 May 2012 10:06:06
>> To: callback-dev@incubator.apache.org<callback-dev@incubator.apache.org>
>> Reply-To: callback-dev@incubator.apache.org
>> Subject: Re: Cordova BlackBerry WebWorks SDKs (5.0 / 6.0 / 7.0 / 10 /
>>  PlayBook)
>>
>> One thing too, that I'd like to point out, is that Tim from Adobe is
>> actively working on the air-for-playbook implementation, so yes, there is
>> a support window, but we DO have a resource to help with that stuff.
>>
>> Also, Gord is supposed to be helping out around here too, right? Eh Gord?
>> ;)
>>
>> On 5/15/12 9:52 AM, "Ken Wallis" <kwallis@rim.com> wrote:
>>
>> >BlackBerry 10 for Playbook delivery is confirmed to happen, but timelines
>> >are "after" delivery for BlackBerry 10 smartphones.  So you will need to
>> >support Air for PlayBook even after the initial launch of BB10 later this
>> >year, unfortunately.
>> >--
>> >
>> >Ken Wallis
>> >
>> >Product Manager ­ BlackBerry WebWorks
>> >
>> >Research In Motion
>> >
>> >(905) 629-4746 x14369
>> >
>> >________________________________________
>> >From: purdrew@gmail.com [purdrew@gmail.com] on behalf of Drew Walters
>> >[deedubbu@gmail.com]
>> >Sent: Tuesday, May 15, 2012 12:22 PM
>> >To: callback-dev@incubator.apache.org
>> >Subject: Re: Cordova BlackBerry WebWorks SDKs (5.0 / 6.0 / 7.0 / 10 /
>> >PlayBook)
>> >
>> >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
>> >accurate.
>> >
>> >https://bdsc.webapps.blackberry.com/devzone/appworld/
>> >
>> >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 <fil@adobe.com> 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" <deedubbu@gmail.com> 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:
>> >>>
>> >>>
>> http://supportforums.blackberry.com/t5/Web-and-WebWorks-Development/BB-1
>> >>>0-
>> >>>WebWorks-Extension/td-p/1715469
>> >>>
>> >>>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 <b@brian.io> 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
>> >>>> <michael@michaelbrooks.ca> wrote:
>> >>>>> Right.
>> >>>>>
>> >>>>> And just to simplify the transition, we would rather not immediately
>> >>>>>rename
>> >>>>> "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
>> >>>>>(removing
>> >>>>> the "incubator" prefix).
>> >>>>>
>> >>>>> Michael
>> >>>>>
>> >>>>> On Mon, May 14, 2012 at 3:35 PM, Filip Maj <fil@adobe.com>
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
>> >>>>>>following
>> >>>>>> the BB10JAM event that the air implementation should keep
us covered
>> >>>>>>on
>> >>>>>> BB7, BB10 and Playbook platforms for a little while (with
the
>> >>>>>>unfortunate
>> >>>>>> 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
>> >>>>>>play
>> >>>>>> books get upgraded to QNX), and we can keep the Java implementation
>> >>>>>>around
>> >>>>>> for BB5/6/7 legacy support.
>> >>>>>>
>> >>>>>> Phew, what a mess.
>> >>>>>>
>> >>
>> >
>> >---------------------------------------------------------------------
>> >This transmission (including any attachments) may contain confidential
>> >information, privileged material (including material protected by the
>> >solicitor-client or other applicable privileges), or constitute
>> >non-public information. Any use of this information by anyone other than
>> >the intended recipient is prohibited. If you have received this
>> >transmission in error, please immediately reply to the sender and delete
>> >this information from your system. Use, dissemination, distribution, or
>> >reproduction of this transmission by unintended recipients is not
>> >authorized and may be unlawful.
>>
>>

Mime
View raw message