incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Wallis <kwal...@rim.com>
Subject RE: one file to rule them all: some post 2.x thoughts
Date Wed, 06 Jun 2012 13:10:04 GMT
You can probably lump BlackBerry 10 into the JavaScript based platform. ;)

We have a similar concept now with a webworks.js file that orchestrates the API loading etc.
--

Ken Wallis

Product Manager – BlackBerry WebWorks

Research In Motion

(905) 629-4746 x14369

________________________________________
From: Dave Johnson [dave.c.johnson@gmail.com]
Sent: Wednesday, June 06, 2012 1:44 AM
To: callback-dev@incubator.apache.org
Cc: gtanner@gmail.com
Subject: Re: one file to rule them all: some post 2.x thoughts

Drew I really like that approach but it doesn't work well in platforms
where there's no "native" code like desktop browser (for debugging)
and JavaScript based platforms like Symbian and webOS (but maybe
that's not such a big deal?).

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

---------------------------------------------------------------------
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