incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laurent Hasson <lhas...@rim.com>
Subject Re: Pluginization FTW
Date Thu, 19 Apr 2012 19:12:03 GMT
Cool. I am good with that. Gord can certainly help with the details.

___________________________________________
LDH (Laurent Hasson)
Technical Director, BlackBerry Web Platform
Research In Motion
Email: lhasson@rim.com
Mobile: 646-460-7066
-----------------------------------------------------------------
"That's who you remind me of: an evil Mr. Rogers!" - Simon Phoenix
-----------------------------------------------------------------
Sent from my BlackBerry Torch!

----- Original Message -----
From: Drew Walters [mailto:deedubbu@gmail.com]
Sent: Thursday, April 19, 2012 12:02 PM
To: callback-dev@incubator.apache.org <callback-dev@incubator.apache.org>
Subject: Re: Pluginization FTW

Laurent, we've been discussing "making everything pluggable" for the
Cordova API across platforms for a while and its somewhere in the
roadmap.  My understanding of the goal is to provide the base Cordova
framework without the API (File, Media, Notification, etc), then
provide a mechanism for the application developer to choose which API
to include through a plugin distribution mechanism.

The work I posted was an exploration into how this could be done on
Cordova BlackBerry.  Each platform would need to figure out how best
to do something similar since the native implementations share no
commonality.

My proposal makes use of all the work that was done on cordova-js and
only requires minimal changes while the majority of the work is on the
native side to refactor into separate Cordova API based plugins.

So, in answer to your question, yes, the granularity would be the same
across platforms.

On Thu, Apr 19, 2012 at 11:24 AM, Laurent Hasson <lhasson@rim.com> wrote:
> Agreed... I am traveling, so didn't get a chance to read too much in deep details...
But ultimately, the art of this is to find the right level of granularity: you don't want
only one giant thing, but you don't want a gazillion tiny things either :)
>
> Where I am a bit confused: wouldn't the granularity for feature be the same across platforms?
One app needs to be able to work across right? Also, for bb-only features, why have a different
impedance than other platforms?
>
>
> ___________________________________________
> LDH (Laurent Hasson)
> Technical Director, BlackBerry Web Platform
> Research In Motion
> Email: lhasson@rim.com
> Mobile: 646-460-7066
> -----------------------------------------------------------------
> "That's who you remind me of: an evil Mr. Rogers!" - Simon Phoenix
> -----------------------------------------------------------------
> Sent from my BlackBerry Torch!
>
> ----- Original Message -----
> From: Ken Wallis [mailto:kwallis@rim.com]
> Sent: Thursday, April 19, 2012 08:07 AM
> To: callback-dev@incubator.apache.org <callback-dev@incubator.apache.org>; callback-dev@incubator.apache.org
<callback-dev@incubator.apache.org>
> Subject: Re: Pluginization FTW
>
> Reading through Drew's initial email a bit more, it seems like it might be beneficial
to have another BlackBerry/Cordova synch-up meeting.  With WebWorks for BlackBerry 10, we
are taking a more Cordova like approach with a WebWorks.js file that you must include, that
handles API loading and whitelisting, etc.
>
> With Cordova's plug-in approach evolving, we were hoping to migrate WebWorks apis into
Cordova extensions sometime in the future.  With Drew's work, it appears almost like we have
some of that, but the flavourful is almost the reverse like massaging Cordova into WebWorks
under the covers.  Would be good to review this and gets clear understanding of the best
way to move forward?
>
> Sent from my BlackBerry® PlayBook™
> www.blackberry.com
>
> ________________________________
> From: "Ken Wallis" <kwallis@rim.com>
> To: "callback-dev@incubator.apache.org" <callback-dev@incubator.apache.org>, "callback-dev@incubator.apache.org"
<callback-dev@incubator.apache.org>
> Sent: April 19, 2012 9:00 AM
> Subject: Re: Pluginization FTW
>
>
> Yup, I was always thinking of each WebWorks feature being its own extension to Cordova.
>
> Sent from my BlackBerry® PlayBook™
> www.blackberry.com
>
> ________________________________
> From: "Drew Walters"
> To: "callback-dev@incubator.apache.org"
> Sent: April 19, 2012 8:35 AM
> Subject: Re: Pluginization FTW
>
>
> I'd be curious to hear the advantages of moving to a single extension.
>  From my experience with having a single extension for Cordova
> BlackBerry here are some of the disadvantages I've come across:
>
> 1. Every application must include the entire set of API whether the
> application needs it or not.
> 2. Every application must include all the permissions required by the
> API whether they are using them or not.
> 3. In order for a third party to "extend" the extension they have to
> copy their source code directly into your extension.  This presents a
> maintenance nightmare when trying to deal with version updates.
>
> One thing I should probably make clear about how I refactored the
> code.  Although there are now extensions for each API feature set, the
> Cordova PluginManager is still the central invocation point and
> manager of plugin lifecycle.  This seems similar to how WebWorks is
> moving to a single XHR invocation point while still maintaining
> separate extensions.
>
> On Wed, Apr 18, 2012 at 7:22 PM, Laurent Hasson  wrote:
>> Converging WW and Cordova is a stated goal on our end :) How we get there is the
fun question. The work Gord has been doing is actually in line with our internal direction,
and I look to Gord to provide the rails to a converged path :)
>>
>>
>> ___________________________________________
>> LDH (Laurent Hasson)
>> Technical Director, BlackBerry Web Platform
>> Research In Motion
>> Email: lhasson@rim.com
>> Mobile: 646-460-7066
>> -----------------------------------------------------------------
>> "That's who you remind me of: an evil Mr. Rogers!" - Simon Phoenix
>> -----------------------------------------------------------------
>> Sent from my BlackBerry Torch!
>>
>> ----- Original Message -----
>> From: Filip Maj [mailto:fil@adobe.com]
>> Sent: Wednesday, April 18, 2012 04:36 PM
>> To: callback-dev@incubator.apache.org
>> Subject: Re: Pluginization FTW
>>
>> Just a quick note, the RIM guys have talked in passing (nothing official -
>> just what I have heard on the interwebz) about actually converting BB
>> WebWorks to more of a (current) cordova implementation, re: single
>> extension for everything. So in terms of being "more compliant" to what
>> WebWorks recommends, what we're doing currently, as far as I understand,
>> may actually be better. Heh.
>>
>> Perhaps Gord/Dan/Ken/Laurent can comment on that in more detail and more
>> authority than I can.
>>
>> On 4/18/12 1:58 PM, "Drew Walters"  wrote:
>>
>>>I've been experimenting with what it would look like for Cordova
>>>BlackBerry to be modified such that all the API are separated out into
>>>plugins. For those that want to cut to the chase, here's my repo:
>>>
>>>https://github.com/deedubbu/cordova-blackberry-pluggable
>>>
>>>This repo is a representation of what the binary download would be for
>>>the end user and is not a fork of either cordova-js or
>>>cordova-blackberry-webworks.  Without being able to see the change
>>>history it might be difficult to tell what I've done so I'll provide
>>>some high level details here:
>>>
>>>1. Separated the native code and associated JavaScript into
>>>independent WebWorks extensions.  Previously there was only a single
>>>extension.  This allows us to make use of the BlackBerry WebWorks
>>>framework build/config tools which handle packaging up only the
>>>necessary code when building an app.
>>>2. All Cordova JavaScript is injected from the native side. No need to
>>>include cordova.js in your application, all the Cordova JavaScript is
>>>loaded before the applications pages load.
>>>3. WebWorks Extension API is hidden behind the existing Cordova Plugin
>>>interface.  Plugin developer doesn't really need to know that they are
>>>developing a WebWorks extension.  The only new interface requirement
>>>for a plugin is to invoke a new constructor.
>>>4. JavaScript API are defined as modules (no change) and can
>>>additionally call cordova.addPlugin(...) or cordova.mergePlugin(...)
>>>to override/merge global namespace.
>>>5. Installation of Cordova is a simple matter of copying a folder to
>>>the WebWorks SDK ext folder.
>>>6. Installation of a Cordova plugin is a simple matter of copying a
>>>folder to the WebWorks SDK ext folder.
>>>7. Enabling a Cordova plugin requires specifying the feature id in
>>>projects config.xml. plugins.xml is not used.
>>>
>>>Ok, that's a quick brain dump. The README contains a few more details.
>>>I plan on eventually pushing branches to my forks for cordova-js and
>>>cordova-blackberry-webworks which will show the actual code changes.
>>
>>
>> ---------------------------------------------------------------------
>> 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.
>
>
> ---------------------------------------------------------------------
> 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.

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