Just my 2 cents on this in regards to the performance argument. The plugin code is not executed unless it is on the platform it targets so the only cost is the initial interpretation of the code and would be directly tied to the size of the file.
the entire cordova.blackberry.js file is currently 343k that contains all three platforms. The average size of cordova.js for all the platforms is 228k and the next largest (windows8) comes in at 282k. Is there a problem in BlackBerry 10 for supporting files larger than 300k? I can't imagine so but do you have a number in mind that would cause issues in the browser that we should keep in mind in case when you start adding in some more code to cordova.blackberry.js we don't reach it. Also with PlayBook migrating to BlackBerry 10 later I would imagine the entire cordova.blackberry.js file will shrink down to the same size as the rest of the platforms as we get get rid of the air platform. On Fri, Feb 22, 2013 at 10:34 AM, Jeffrey Heifetz <jheif...@rim.com> wrote: > Hey Brian, > > BB10 is not just a specific version number of an SDK like BBOS v 10, its > a brand new OS. Like Mac OSX vs Classical Mac OS. But independent of the > technology differences I believe this approach will improve things for > cordova developers targeting blackberry by making it more consistent with > the approach taken with other platforms. > > Firstly the developer experience for developers targeting both BB10 and > one of BBOS and PBOS. The current implementation based on 3 slightly > different versions of webworks means that there are similar things that end > up acting quite differently. One example is the config.xml. Currently the > solution is that Cordova populates one massive config.xml that attempts to > satisfy all 3 sub-platforms and cordova at large as well. Unfortunately the > SDKS are quite different offering very different functionalities through > the config, and there is currently no way to handle these differences in > the sub-platforms. > By splitting we can handle these in the same way all other cordova > platforms do (unsure what this is) and once the core plugins are split > accurately let the individual plugins add these values accordingly > (something that may not be possible when BBOS and PBOS share a config entry > but BB10 does not). > > Even developer experience for developers making cross platform plugins > thinking to add support for blackberry. Currently blackberry has a unique > structure requiring plugins to have their code in a specific way for 3 > different platforms. While adding support for just one is not difficult, > its different from any other platform (to my knowledge). > > Another example will be simple performance. The way the repo is > architected right now, javascript is loaded that runs for all 3 platforms > and it runtime detects which one to use. Its not even clear how this will > work once all of the plugins are split into their own repos, but having > this adds unnecessary complications that can be removed. > > We're in the midst of getting our code up on github, maybe it'll be > clearer what we want to do when there's code to see. > > On 2013-02-20, at 12:47 PM, Brian LeRoux wrote: > > > Hey Jeffrey, I'm sorry but I'm not convinced by 'its cleaner' as an > > argument. Its not. Its a specific version number to a specific SDK. I > > understand that you have more than one SDK: this is common in mobile > > platforms, and addressed by the current repo. > > > > Can you be more precise and explain exactly what you envision this new > > repo to contain, and specifically why it can't come as a pull request > > to the existing repo/codebase? > > > > > > On Tue, Feb 19, 2013 at 5:47 PM, Jeffrey Heifetz <jheif...@rim.com> > wrote: > >> Sharzon, sorry I have no clue when BB10 will be making its way to > playbook. > >> > >> Bryan, whatever the next version is called BB11 or not, that would > still be within the same repo. Conceptually BB10 is a brand new platform > based on a very different SDK and unless I'm mistaken BlackBerry is the > only platform to have 3 different SDKS within one repo (BBOS java, AIR, and > BB10 C++). I know windows phone is separated. Plus we feel this way it > will be cleanest for our developers and more conformant with the cordova > dev experience. > >> > >> Tim we're in the midst of creating a much more CLI friendly (Not ANT) > repo right now that would be based on our last webworks packager and > framework but would be built directly on the NDK. > >> > >> As per the plugins, I'll take a look tomorrow but it's impressive when > anyone makes a plugin for bb1010. Current docs are definitely lacking. > >> > >> Sent from my BlackBerry 10 smartphone. > >> > >> From: Tim Kim > >> Sent: Tuesday, February 19, 2013 7:11 PM > >> To: dev@cordova.apache.org > >> Reply To: dev@cordova.apache.org > >> Subject: Re: Proposition to split cordova-blackberry into two separate > plugins > >> > >> > >> I don't mind either way, but I think we should have at least an idea > what > >> the cordova-blackberry10 repo should look like before we create it. > >> To separate them right now would mean creating two very similar > >> cordova-blackberry repos (everything the same except some build > scripts). > >> And then later on, reconfiguring the cordova-blackberry10 repo to be > >> whatever. > >> > >> So I'm basically for less work now :) > >> > >> Also, on the topic of plugins for BlackBerry 10, I've done some work > >> recently on this that you can check out: > >> > >> Here's my simple plugin that shows the structure for a BB10 plugin with > >> native code: > >> https://github.com/timkim/cordova.echo > >> > >> A tool to build the C++ code from command line: > >> https://github.com/timkim/Renton > >> > >> And plugman now has bb10 support so it should be able to install the > >> cordova.echo plugin: > >> https://github.com/imhotep/plugman > >> > >> > >> > >> > >> On 19 February 2013 14:55, Brian LeRoux <b...@brian.io> wrote: > >> > >>> I'm a little uncertain about the reasoning here. What happens when BB11 > >>> ships? New repo? > >>> > >>> Generally we try to keep things in a vendor directory with > >>> the pertinent SDK's within. What is wrong w/ the current structure for > >>> contribution? > >>> > >>> > >>> > >>> On Tue, Feb 19, 2013 at 2:45 PM, Shazron <shaz...@gmail.com> wrote: > >>> > >>>> +1 > >>>> Also, any news when BB10 comes to Playbook, ballpark? --> "once BB10 > is > >>>> ported to playbook" > >>>> > >>>> > >>>> > >>>> On Tue, Feb 19, 2013 at 1:24 PM, Filip Maj <f...@adobe.com> wrote: > >>>> > >>>>> Sounds fine to me. > >>>>> > >>>>> As for process, assuming there are no objections (would wait a couple > >>>>> days), file a JIRA issue on the INFRA project > >>>>> (issues.apache.org/jira/browser/INFRA) > >>>>> > >>>>> On 2/19/13 1:15 PM, "Jeffrey Heifetz" <jheif...@rim.com> wrote: > >>>>> > >>>>>> With all this talk of re-organizing cordova plugins we here at > >>>> BlackBerry > >>>>>> (RIM no more) have been discussing better alleging ourselves with > the > >>>>>> approach by splitting our existing cordova-blackberry platform into > >>> two > >>>>>> separate platforms. (I saw a similar call here as well > >>>>>> > >>>>> > >>>> > >>> > http://callback.markmail.org/thread/xnhpidbnxg5ps7zr#query:+page:1+mid:xnh > >>>>>> pidbnxg5ps7zr+state:results) > >>>>>> > >>>>>> We propose adding a new platform, "blackberry10" with the longterm > >>>>>> understanding that once BB10 is ported to playbook the original repo > >>>>>> would only be for BBOS. Ideally the end result of this is that we > >>> would > >>>>>> have an up to date cordova-blackberry10 platform following all of > the > >>>>>> best practices (plugins moved into their own repos, etc) and we can > >>>>>> better contribute resources to Cordova in general. > >>>>>> > >>>>>> Hopefully no one has any objections to this as structurally they are > >>>>>> really separate platforms. Additionally it'll make the flow within > >>> CLI a > >>>>>> lot cleaner. > >>>>>> > >>>>>> If everyone agrees, what is the process for getting a new apache > repo > >>>> for > >>>>>> it? > >>>>>> > >>>>>> > --------------------------------------------------------------------- > >>>>>> 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. > >>>>> > >>>>> > >>>> > >>> > >> > >> > >> > >> -- > >> Timothy Kim > >> > >> > >> > >> > >> > >> > >> > >> > >> --------------------------------------------------------------------- > >> 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. > > > --------------------------------------------------------------------- > 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. >
