Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Ken Wallis <kwallis@rim.com>
To: "callback-dev@incubator.apache.org" <callback-dev@incubator.apache.org>
CC: "gtanner@gmail.com" <gtanner@gmail.com>
Subject: RE: one file to rule them all: some post 2.x thoughts
Thread-Topic: one file to rule them all: some post 2.x thoughts
Thread-Index: 
 AQHNQ2YmeXEOzgHgTU2ATro4EHxRxpbsjDMAgAADC4CAAAbwgIAAD1EAgAAOSICAABTDAIAAQpaAgAA5KlE=
Date: Wed, 6 Jun 2012 13:10:04 +0000
Message-ID: <42C7A58253BA3C44BE8534C00002182A22338D@XMB117CNC.rim.net>
References: 
 <CADVgkyPMs=Nyzp=k-GR4wAPsY+z+0OOwBWBtu2XEmw3ZKC2LTA@mail.gmail.com>
 <CAP7NMPpo0ZtKBNNBR6-Ojt9+ALoau05EwwQn8AXWGaNFyViSjw@mail.gmail.com>
 <CAKP6k2v2vFzAExYbH9ZRdNv=VSaHg3tw-NHTcEcwv0dkc1C8fw@mail.gmail.com>
 <CANpVHHzffSUT0NBnNXhL7pOzouspKK_6gC1ZQwnnqh1aVMaGzw@mail.gmail.com>
 <1524511009-1338939637-cardhu_decombobulator_blackberry.rim.net-805335093-@b18.c19.bise6.blackberry>
 <CAP7NMPpLw+VBNw9KcxSSfspiWD1OKD3-6k=UU-xnEDxgSvZf6A@mail.gmail.com>
 <CAO_65gxBSawfiADqoZ4xsm=V-MXCXyahjsGJ81+u5cX4=Q4P8g@mail.gmail.com>,<CADq=2H6dSacqqr3mV8KFkyLJQjq4VoMrSSBgRMd_M9giJZm=zA@mail.gmail.com>
In-Reply-To: 
 <CADq=2H6dSacqqr3mV8KFkyLJQjq4VoMrSSBgRMd_M9giJZm=zA@mail.gmail.com>
Accept-Language: en-US, en-CA
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0

You can probably lump BlackBerry 10 into the JavaScript based platform. ;)=
=0A=
=0A=
We have a similar concept now with a webworks.js file that orchestrates the=
 API loading etc.=0A=
--=0A=
=0A=
Ken Wallis=0A=
=0A=
Product Manager =96 BlackBerry WebWorks=0A=
=0A=
Research In Motion=0A=
=0A=
(905) 629-4746 x14369=0A=
=0A=
________________________________________=0A=
From: Dave Johnson [dave.c.johnson@gmail.com]=0A=
Sent: Wednesday, June 06, 2012 1:44 AM=0A=
To: callback-dev@incubator.apache.org=0A=
Cc: gtanner@gmail.com=0A=
Subject: Re: one file to rule them all: some post 2.x thoughts=0A=
=0A=
Drew I really like that approach but it doesn't work well in platforms=0A=
where there's no "native" code like desktop browser (for debugging)=0A=
and JavaScript based platforms like Symbian and webOS (but maybe=0A=
that's not such a big deal?).=0A=
=0A=
On Tue, Jun 5, 2012 at 6:46 PM, Drew Walters <deedubbu@gmail.com> wrote:=0A=
> I think we discussed this previously, but what's the potential for the=0A=
> native side to just load the cordova.js/plugin javascript dynamically=0A=
> at initialization rather then requiring each app to specify it in the=0A=
> HTML content. This is what I did in my refactor of Cordova BlackBerry=0A=
> where everything is a plugin.  I recall there being an issue with iOS=0A=
> / Android doing something similar but not sure.=0A=
>=0A=
> On Tue, Jun 5, 2012 at 7:31 PM, Michael Brooks <michael@michaelbrooks.ca>=
 wrote:=0A=
>> Jesse / Fil / Gord / Anis, I think we're all in agreement but our=0A=
>> suggestions are for different stages of the problem.=0A=
>>=0A=
>> Today: The easiest is pre-building a monolith file with all plugins and=
=0A=
>> platform-specifics.=0A=
>>=0A=
>> Tomorrow: Loading only necessary the plugins as modules (or some concat=
=0A=
>> variation).=0A=
>>=0A=
>> In both: We offer a "debug" JavaScript that detects the platform and load=
s=0A=
>> the platform-specifics. For the performance hungry, they can opt into a=
=0A=
>> slimmer "prod" JavaScript that only includes a specific platform. All of=
=0A=
>> these JavaScript files can be pre-built and shipped, so the end-users do=
=0A=
>> not need to run cordova-js.=0A=
>>=0A=
>> Michael=0A=
>>=0A=
>> On Tue, Jun 5, 2012 at 4:40 PM, <gtanner@gmail.com> wrote:=0A=
>>=0A=
>>> I have really liked the mobile-spec cordova.js file (option 2). If we ha=
ve=0A=
>>> enough runtime information to figure out the platform (is useragent=0A=
>>> enough?) we could continue building platform specific files and include=
=0A=
>>> them at runtime.=0A=
>>>=0A=
>>> Could then be handled better via the cmdline tooling to only include=0A=
>>> platforms they care about.:=0A=
>>>=0A=
>>> cordova add ios=0A=
>>> cordova add blackberry=0A=
>>>=0A=
>>> ...=0A=
>>> Sent on the TELUS Mobility network with BlackBerry=0A=
>>>=0A=
>>> -----Original Message-----=0A=
>>> From: Anis KADRI <anis.kadri@gmail.com>=0A=
>>> Date: Tue, 5 Jun 2012 15:45:53=0A=
>>> To: <callback-dev@incubator.apache.org>=0A=
>>> Reply-To: callback-dev@incubator.apache.org=0A=
>>> Subject: Re: one file to rule them all: some post 2.x thoughts=0A=
>>>=0A=
>>> I vote for including the javascript generation as part of the build proc=
ess=0A=
>>> (or separate).=0A=
>>> It could:=0A=
>>> - include the plugins that are needed (contacts, etc...).=0A=
>>> - use the right exec method and inludes the right  platform-specific cod=
e.=0A=
>>>=0A=
>>> Pretty much what cordova-js does right now with the ability to select wh=
at=0A=
>>> plugins you want.=0A=
>>>=0A=
>>> advantages:=0A=
>>> - smaller file that just includes what you need in terms of plugins. Fas=
ter=0A=
>>> load time.=0A=
>>> - Doesn't include plugins that are not supported by the targeted platfor=
m.=0A=
>>>=0A=
>>> I find it easier to deal with one file that has everything I need rather=
=0A=
>>> than having to include multiple files. but that is just me.=0A=
>>> On Tue, Jun 5, 2012 at 3:21 PM, Jesse <purplecabbage@gmail.com> wrote:=
=0A=
>>>=0A=
>>> > I originally envisioned something like #1, except that the individual=
=0A=
>>> APIs=0A=
>>> > would not be part of the master file.=0A=
>>> > ie. real modules, the cordova-common.js would just provide the transpo=
rt,=0A=
>>> > and fire the correct events.  If you want to use Contacts, then you=
=0A=
>>> simply=0A=
>>> > add an include script tag for cdv-contacts.js=0A=
>>> > This would be just like any other plugin ...=0A=
>>> >=0A=
>>> > We already employ this type of modular-izing in mobile-spec in that an=
y=0A=
>>> > tests you want to run must be included in the page.=0A=
>>> >=0A=
>>> > On Tue, Jun 5, 2012 at 3:10 PM, Michael Brooks <michael@michaelbrooks.=
ca=0A=
>>> > >wrote:=0A=
>>> >=0A=
>>> > > A small variation of 1)=0A=
>>> > >=0A=
>>> > > 1) Ship all platform-specific JavaScript in one file and sort it out=
 at=0A=
>>> > > runtime. Provide the option to build the JavaScript for a specific=
=0A=
>>> > > platform. Basically, a debug vs production file, although most apps=
=0A=
>>> would=0A=
>>> > > happily use the debug in production.=0A=
>>> > >=0A=
>>> > > On Tue, Jun 5, 2012 at 2:56 PM, Brian LeRoux <brian.leroux@gmail.com=
>=0A=
>>> > > wrote:=0A=
>>> > >=0A=
>>> > > > Just had a water cooler discussion about the holy grail of having=
 one=0A=
>>> > > > js file to rule them all.=0A=
>>> > > >=0A=
>>> > > > 1. platforms have differences but could it be feasible to ship all=
=0A=
>>> > > > those differences in the single file and sort out which traits to=
=0A=
>>> load=0A=
>>> > > > at runtime. this would certainly introduce a latency and parse hit=
.=0A=
>>> > > > this would force us to really be thinking about a protocol to=0A=
>>> minimize=0A=
>>> > > > platform differences instead of brute forcing it.=0A=
>>> > > >=0A=
>>> > > > 2. the cordova.js file could document.write a script tag including=
=0A=
>>> the=0A=
>>> > > > auto compiled src file (still doing different files for each platf=
orm=0A=
>>> > > > but the src would feel cleaner to end developers). same performanc=
e=0A=
>>> we=0A=
>>> > > > have today.=0A=
>>> > > >=0A=
>>> > > > 3. do as we do today: different files for every platform treated a=
s a=0A=
>>> > > > build artifact.=0A=
>>> > > >=0A=
>>> > >=0A=
>>> >=0A=
>>> >=0A=
>>> >=0A=
>>> > --=0A=
>>> > @purplecabbage=0A=
>>> > risingj.com=0A=
>>> >=0A=
>>>=0A=
>>>=0A=

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient 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 immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.