Thanks Ken, I'll start parsing through that. .....remembering how much I loathe c++.....
On Tue, May 15, 2012 at 10:08 AM, Ken Wallis <kwal...@rim.com> wrote: > We haven't officially announced support for custom extensions because we are > still not 100% confident in how the API extension mechanism will actually > play out on top of the Native platform. It is still a work in progress, but > I would say we are closer to 80% confident. If we wanted to get started, we > could probably with a 20% potential for a refactor. ;) > > You can take a look at our BB10/C++ API implementations here: > https://github.com/blackberry-webworks/BB10-WebWorks-Framework/tree/next/ext > > A good one as a model might be the new dialog implementation: > https://github.com/blackberry-webworks/BB10-WebWorks-Framework/tree/next/ext/blackberry.ui.dialog > > > -- > > Ken Wallis > > Product Manager – BlackBerry WebWorks > > Research In Motion > > (905) 629-4746 x14369 > > ________________________________________ > From: purd...@gmail.com [purd...@gmail.com] on behalf of Drew Walters > [deedu...@gmail.com] > Sent: Tuesday, May 15, 2012 9:20 AM > To: callback-dev@incubator.apache.org > Subject: Re: Cordova BlackBerry WebWorks SDKs (5.0 / 6.0 / 7.0 / 10 / > PlayBook) > > 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-10-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 >> <mich...@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 <f...@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.
