incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gord Tanner <gtan...@gmail.com>
Subject Re: one file to rule them all: some post 2.x thoughts
Date Mon, 11 Jun 2012 14:22:56 GMT
Having one JS file to rule them all would be a very interesting aspect for
testing via Ripple.  Currently we are dealing with trying to steal out the
exec module from under the nose of the current platform:

https://github.com/tinyhippos/Ripple-UI/blob/master/lib/ripple/platform/cordova/1.6/spec.js#L27-30

We are currently heads down attempting to fix a bug where we somehow have
the old version of exec closured (even though we have replaced it earlier).

If we could ship cordova.ripple.js in the cordova.js project it would make
our code a lot simpler for emulation (Ripple could include the file for now
and cordova command line could build it later).


On Wed, Jun 6, 2012 at 1:14 PM, Ken Wallis <kwallis@rim.com> wrote:

> Our packager will include any, but only those API packages called out in
> config.xml.  Further, the webworks.js framework will validate that the
> current domain actually has access to a given API based on our whitelisting
> rules (also in config.xml), and prevent access with an error if denied.
>
> --
>
> 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: Wednesday, June 06, 2012 9:48 AM
> To: callback-dev@incubator.apache.org
> Cc: gtanner@gmail.com
> Subject: Re: one file to rule them all: some post 2.x thoughts
>
> So with BlackBerry 10 I would assume the webworks.js is dynamically
> built by the packager based on the extensions specified in config.xml
> right?
>
> I would think this is what we would eventually do in Cordova. It seems
> to me our build tools for the various platforms should just be
> configured to point to where the Cordova SDK is and then the build can
> dynamically build a platform specific cordova.js file that is packaged
> with the application.
>
> On Wed, Jun 6, 2012 at 8:10 AM, Ken Wallis <kwallis@rim.com> wrote:
> > 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.
>
> ---------------------------------------------------------------------
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message