You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Drew Walters <de...@gmail.com> on 2012/04/18 22:58:26 UTC
Pluginization FTW
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.
Re: Pluginization FTW
Posted by Laurent Hasson <lh...@rim.com>.
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 <ca...@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 <lh...@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 <ca...@incubator.apache.org>; callback-dev@incubator.apache.org <ca...@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" <kw...@rim.com>
> To: "callback-dev@incubator.apache.org" <ca...@incubator.apache.org>, "callback-dev@incubator.apache.org" <ca...@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.
Re: Pluginization FTW
Posted by Drew Walters <de...@gmail.com>.
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 <lh...@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 <ca...@incubator.apache.org>; callback-dev@incubator.apache.org <ca...@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" <kw...@rim.com>
> To: "callback-dev@incubator.apache.org" <ca...@incubator.apache.org>, "callback-dev@incubator.apache.org" <ca...@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.
Re: Pluginization FTW
Posted by Patrick Mueller <pm...@gmail.com>.
This is just a meta-comment, since I really don't know anything about BB/WW
I think there's all kinds of headroom available, with the way we have
things structured right now, to mix-and-match our atomic bits - the cordova
modules - into various shapes.
* I've been lightly experimenting and pushing other AMD runtimes to help
out with a story where we take our modules, but use their module runtime.
Not quite there yet. Seems totally do-able to me though.
* You should be able to use our modules with Browserify, if you want.
Haven't tried. Bonuses with Browserify is you get some amount of node.js
support (some built-in node modules are supported), as well as
__filename/__dirname support in your module at runtime (those aren't
available using our runtime (yet) nor AMD runtimes).
* You should be able to use our modules with node.js directly, though they
likely "won't work" because of the native ties via exec etal. But a
"platform" like errgen >should< work. We don't currently "package" a
node.js-able errgen platform, but I believe we could.
* packaging platform APIs as Cordova modules. So, this is a new one to me,
but is the sense of what I'm hearing on this thread, that somehow WebWorks
APIs can be surfaced as Cordova modules. I don't see a problem with this,
but honestly don't really see the immediate value either. Kinda of a
question of "who owns the platform". I can easily see folks like AppLaud
or WorkLight extending the "Cordova platform" story with their own plugins,
though. For an actual platform provider though, one of the options is to
surface Cordova bits AS your platform bits, rather than vice versa.
* even in the previous note, about folks using Cordova as an extendable
platform, folks should have the ability to swizzle the module runtime
environment the way they want.
There's More Than One Way To Do It. :-)
At some point, it will become obvious to us - Cordova devs - as well as
folks who reship Cordova, how they want to use it, how they want to
mix-and-match bits, what options they want to provide to their users. We
don't have to >ship< all the various options, but I'd love to keep it
open-ended so that folks can build their flavorite story with our bits. We
may, however, want to add some tests to make sure that, eg, the AMD almond
loader can be used in lieu of our module runtime, which should be (some
day) dirt easy and quick to build and test (prolly with the errgen or test
platform).
I've done a bit of playing myself in the "what kind of things can we build
with the atomic units" wrt: the "errgen" platform and the "-debug" versions
of the cordova.js files, and even little toolies like the hack-o-rama that
is the module dependencies chart generator via graphviz.
So, love to see experiments and discussion about this stuff. Bring It On.
If it's not intrusive to our current thread of work, adding more "stuff"
to the cordova-js project is great, as it makes it more visible to
everyone.
On Thu, Apr 19, 2012 at 09:07, Ken Wallis <kw...@rim.com> wrote:
> 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" <kw...@rim.com>
> To: "callback-dev@incubator.apache.org" <ca...@incubator.apache.org>,
> "callback-dev@incubator.apache.org" <ca...@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.
>
--
Patrick Mueller
http://muellerware.org
Re: Pluginization FTW
Posted by Laurent Hasson <lh...@rim.com>.
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 <ca...@incubator.apache.org>; callback-dev@incubator.apache.org <ca...@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" <kw...@rim.com>
To: "callback-dev@incubator.apache.org" <ca...@incubator.apache.org>, "callback-dev@incubator.apache.org" <ca...@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.
Re: Pluginization FTW
Posted by Ken Wallis <kw...@rim.com>.
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" <kw...@rim.com>
To: "callback-dev@incubator.apache.org" <ca...@incubator.apache.org>, "callback-dev@incubator.apache.org" <ca...@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.
Re: Pluginization FTW
Posted by Ken Wallis <kw...@rim.com>.
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" <de...@gmail.com>
To: "callback-dev@incubator.apache.org" <ca...@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.
Re: Pluginization FTW
Posted by Drew Walters <de...@gmail.com>.
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 <lh...@rim.com> 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 <ca...@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" <de...@gmail.com> 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.
Re: Pluginization FTW
Posted by Laurent Hasson <lh...@rim.com>.
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 <ca...@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" <de...@gmail.com> 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.
Re: Pluginization FTW
Posted by Filip Maj <fi...@adobe.com>.
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" <de...@gmail.com> 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.
Re: Pluginization FTW
Posted by Drew Walters <de...@gmail.com>.
So, on BlackBerry it is possible to bundle additional resources with
the native code. If you throw the images in the Java source tree, they
get packaged up with the application and can be used by the native
code. I pushed an implementation of the ChildBrowser plugin [1] to my
repo which exhibits this strategy. The icons for the browser toolbar
are bundled with the native code and then accessible at run time. I
updated the sample to have child browser invocation as well.
However, there doesn't seem to be a declarative way to specify
additional resources. The WebWorks packager will only pull in
additional extensions, javascript, java src trees, compiled libraries
specified in the library.xml for the extension. It does not provide a
mechanism to specify arbitrary files that I can tell. It would be nice
to be able to specify things like images in library.xml. Currently,
if the extension javascript needs to reference an image, I don't see a
way of bundling that image.
[1] https://github.com/deedubbu/cordova-blackberry-pluggable/tree/master/ext/cordova.childbrowser
On Thu, Apr 26, 2012 at 3:23 PM, Filip Maj <fi...@adobe.com> wrote:
> Nice, I'm really liking this. Simpler than the massive object with various
> "path" properties, etc.
>
> I think we're getting closer to formalizing this!
>
> One outstanding question is: resources. Image files or anything of that
> like that may be necessary for a plugin.
>
> On 4/26/12 1:09 PM, "Drew Walters" <de...@gmail.com> wrote:
>
>>In case it wasn't clear, in my implementation the plugins do use the
>>builder (modified version) to augment / extend namespace DOM. I
>>realize its difficult to tell right now what I changed but there is a
>>concatenated cordova.js (require.js, cordova.js, builder.js, utils.js,
>>channel.js, bootstrap.js) which has the modified cordova.addPlugin and
>>the modified builder:
>>
>>https://github.com/deedubbu/cordova-blackberry-pluggable/blob/master/ext/c
>>ordova.core/js/common/cordova.js
>>
>>I simplified the interface to it to just take strings such that the
>>plugin simply calls:
>>
>>cordova.addPlugin('navigator.battery', 'cordova/plugin/battery', false);
>>
>>to add the module at navigator.battery and the builder code handles
>>parsing 'navigator.battery' and doing proper merging/overriding.
>>
>>On Thu, Apr 26, 2012 at 2:57 PM, Gord Tanner <go...@tinyhippos.com> wrote:
>>> I would like to have a single module that holds all of the native to
>>> javascript code.
>>>
>>> so:
>>> - exec
>>> - successCallback
>>> - errorCallback
>>> - nativeReady stuff
>>>
>>> kinda a one stop shop for all things native bridge like.
>>>
>>> I don't like how it is mixed together with the cordova module right now.
>>>
>>> cordova as a module should really just have:
>>>
>>> require
>>> define
>>>
>>>
>>> On Thu, Apr 26, 2012 at 3:36 PM, Filip Maj <fi...@adobe.com> wrote:
>>>
>>>> Love this.
>>>>
>>>> What is the refactor of the bridge out of exec, exactly?
>>>>
>>>> On 4/26/12 12:26 PM, "Gord Tanner" <go...@tinyhippos.com> wrote:
>>>>
>>>> >I would imagine plugins should be able to use the builder code
>>>>cordova.js
>>>> >uses to augment or extend namespaces in the dom:
>>>> >
>>>> >
>>>>
>>>>https://github.com/apache/incubator-cordova-js/blob/master/lib/common/co
>>>>mm
>>>> >on.js
>>>> >
>>>> >Builder:
>>>> >
>>>>
>>>>https://github.com/apache/incubator-cordova-js/blob/master/lib/common/bu
>>>>il
>>>> >der.js
>>>> >
>>>> >We do need to clean this API up a bit before exposing it to the
>>>>masses,
>>>> >but
>>>> >it would be neat if a plugin module could use this to drop objects
>>>>into
>>>> >the
>>>> >dom:
>>>> >
>>>> >var objects = { foo: { path: "myplugin/foo"};
>>>> >var builder = cordova.require('cordova/builder');
>>>> >
>>>> >builder.build(objects).into(navigator);
>>>> >
>>>> >An awesome approach for plugin's would be to not to provide a
>>>>platform,
>>>> >but
>>>> >more of a collection of tools (a la unix) that would make it easy for
>>>>them
>>>> >to develop.
>>>> >
>>>> >- cordova.require and cordova.define (they can package themselves as a
>>>> >module and gateway to use our modules)
>>>> >- cordova/exec (would be nice to finally refactor out the
>>>>cordova/bridge
>>>> >module)
>>>> >- cordova/utils (toolbox stuff)
>>>> >- cordova/builder (better API needed for building up dom namespaces,
>>>>not
>>>> >required but there to use)
>>>> >
>>>> >
>>>> >
>>>> >On Thu, Apr 26, 2012 at 3:05 PM, Brian LeRoux <b...@brian.io> wrote:
>>>> >
>>>> >> On Wed, Apr 25, 2012 at 5:29 AM, Drew Walters <de...@gmail.com>
>>>> >>wrote:
>>>> >> > I would agree that it shouldn't be "necessary" for the addPlugin
>>>>API
>>>> >> > (more like addNamespace), however it was nice to have during my
>>>> >> > development. If you look at the addPlugin API you'll notice it
>>>>waits
>>>> >> > until DOMContentLoaded is fired so that the native browser globals
>>>> >> > don't overwrite the plugin. It then calls a modified builder
>>>>module
>>>> >> > which handles overriding/merging in the various properties of the
>>>> >> > plugin.
>>>> >>
>>>> >> Seems like a docs issue more of an API surface issue to me.
>>>> >>
>>>> >> > Without addPlugin/mergePlugin there will certainly be repetition
>>>>of
>>>> >> > code and greater potential for plugins to unintentionally override
>>>> >> > namespace of other plugins.
>>>> >>
>>>> >> could add those to util
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> >--
>>>> >Gord Tanner
>>>> >Senior Developer / Code Poet
>>>> >tinyHippos Inc.
>>>> >@tinyhippos
>>>>
>>>>
>>>
>>>
>>> --
>>> Gord Tanner
>>> Senior Developer / Code Poet
>>> tinyHippos Inc.
>>> @tinyhippos
>
Re: Pluginization FTW
Posted by Filip Maj <fi...@adobe.com>.
Nice, I'm really liking this. Simpler than the massive object with various
"path" properties, etc.
I think we're getting closer to formalizing this!
One outstanding question is: resources. Image files or anything of that
like that may be necessary for a plugin.
On 4/26/12 1:09 PM, "Drew Walters" <de...@gmail.com> wrote:
>In case it wasn't clear, in my implementation the plugins do use the
>builder (modified version) to augment / extend namespace DOM. I
>realize its difficult to tell right now what I changed but there is a
>concatenated cordova.js (require.js, cordova.js, builder.js, utils.js,
>channel.js, bootstrap.js) which has the modified cordova.addPlugin and
>the modified builder:
>
>https://github.com/deedubbu/cordova-blackberry-pluggable/blob/master/ext/c
>ordova.core/js/common/cordova.js
>
>I simplified the interface to it to just take strings such that the
>plugin simply calls:
>
>cordova.addPlugin('navigator.battery', 'cordova/plugin/battery', false);
>
>to add the module at navigator.battery and the builder code handles
>parsing 'navigator.battery' and doing proper merging/overriding.
>
>On Thu, Apr 26, 2012 at 2:57 PM, Gord Tanner <go...@tinyhippos.com> wrote:
>> I would like to have a single module that holds all of the native to
>> javascript code.
>>
>> so:
>> - exec
>> - successCallback
>> - errorCallback
>> - nativeReady stuff
>>
>> kinda a one stop shop for all things native bridge like.
>>
>> I don't like how it is mixed together with the cordova module right now.
>>
>> cordova as a module should really just have:
>>
>> require
>> define
>>
>>
>> On Thu, Apr 26, 2012 at 3:36 PM, Filip Maj <fi...@adobe.com> wrote:
>>
>>> Love this.
>>>
>>> What is the refactor of the bridge out of exec, exactly?
>>>
>>> On 4/26/12 12:26 PM, "Gord Tanner" <go...@tinyhippos.com> wrote:
>>>
>>> >I would imagine plugins should be able to use the builder code
>>>cordova.js
>>> >uses to augment or extend namespaces in the dom:
>>> >
>>> >
>>>
>>>https://github.com/apache/incubator-cordova-js/blob/master/lib/common/co
>>>mm
>>> >on.js
>>> >
>>> >Builder:
>>> >
>>>
>>>https://github.com/apache/incubator-cordova-js/blob/master/lib/common/bu
>>>il
>>> >der.js
>>> >
>>> >We do need to clean this API up a bit before exposing it to the
>>>masses,
>>> >but
>>> >it would be neat if a plugin module could use this to drop objects
>>>into
>>> >the
>>> >dom:
>>> >
>>> >var objects = { foo: { path: "myplugin/foo"};
>>> >var builder = cordova.require('cordova/builder');
>>> >
>>> >builder.build(objects).into(navigator);
>>> >
>>> >An awesome approach for plugin's would be to not to provide a
>>>platform,
>>> >but
>>> >more of a collection of tools (a la unix) that would make it easy for
>>>them
>>> >to develop.
>>> >
>>> >- cordova.require and cordova.define (they can package themselves as a
>>> >module and gateway to use our modules)
>>> >- cordova/exec (would be nice to finally refactor out the
>>>cordova/bridge
>>> >module)
>>> >- cordova/utils (toolbox stuff)
>>> >- cordova/builder (better API needed for building up dom namespaces,
>>>not
>>> >required but there to use)
>>> >
>>> >
>>> >
>>> >On Thu, Apr 26, 2012 at 3:05 PM, Brian LeRoux <b...@brian.io> wrote:
>>> >
>>> >> On Wed, Apr 25, 2012 at 5:29 AM, Drew Walters <de...@gmail.com>
>>> >>wrote:
>>> >> > I would agree that it shouldn't be "necessary" for the addPlugin
>>>API
>>> >> > (more like addNamespace), however it was nice to have during my
>>> >> > development. If you look at the addPlugin API you'll notice it
>>>waits
>>> >> > until DOMContentLoaded is fired so that the native browser globals
>>> >> > don't overwrite the plugin. It then calls a modified builder
>>>module
>>> >> > which handles overriding/merging in the various properties of the
>>> >> > plugin.
>>> >>
>>> >> Seems like a docs issue more of an API surface issue to me.
>>> >>
>>> >> > Without addPlugin/mergePlugin there will certainly be repetition
>>>of
>>> >> > code and greater potential for plugins to unintentionally override
>>> >> > namespace of other plugins.
>>> >>
>>> >> could add those to util
>>> >>
>>> >
>>> >
>>> >
>>> >--
>>> >Gord Tanner
>>> >Senior Developer / Code Poet
>>> >tinyHippos Inc.
>>> >@tinyhippos
>>>
>>>
>>
>>
>> --
>> Gord Tanner
>> Senior Developer / Code Poet
>> tinyHippos Inc.
>> @tinyhippos
Re: Pluginization FTW
Posted by Drew Walters <de...@gmail.com>.
In case it wasn't clear, in my implementation the plugins do use the
builder (modified version) to augment / extend namespace DOM. I
realize its difficult to tell right now what I changed but there is a
concatenated cordova.js (require.js, cordova.js, builder.js, utils.js,
channel.js, bootstrap.js) which has the modified cordova.addPlugin and
the modified builder:
https://github.com/deedubbu/cordova-blackberry-pluggable/blob/master/ext/cordova.core/js/common/cordova.js
I simplified the interface to it to just take strings such that the
plugin simply calls:
cordova.addPlugin('navigator.battery', 'cordova/plugin/battery', false);
to add the module at navigator.battery and the builder code handles
parsing 'navigator.battery' and doing proper merging/overriding.
On Thu, Apr 26, 2012 at 2:57 PM, Gord Tanner <go...@tinyhippos.com> wrote:
> I would like to have a single module that holds all of the native to
> javascript code.
>
> so:
> - exec
> - successCallback
> - errorCallback
> - nativeReady stuff
>
> kinda a one stop shop for all things native bridge like.
>
> I don't like how it is mixed together with the cordova module right now.
>
> cordova as a module should really just have:
>
> require
> define
>
>
> On Thu, Apr 26, 2012 at 3:36 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> Love this.
>>
>> What is the refactor of the bridge out of exec, exactly?
>>
>> On 4/26/12 12:26 PM, "Gord Tanner" <go...@tinyhippos.com> wrote:
>>
>> >I would imagine plugins should be able to use the builder code cordova.js
>> >uses to augment or extend namespaces in the dom:
>> >
>> >
>> https://github.com/apache/incubator-cordova-js/blob/master/lib/common/comm
>> >on.js
>> >
>> >Builder:
>> >
>> https://github.com/apache/incubator-cordova-js/blob/master/lib/common/buil
>> >der.js
>> >
>> >We do need to clean this API up a bit before exposing it to the masses,
>> >but
>> >it would be neat if a plugin module could use this to drop objects into
>> >the
>> >dom:
>> >
>> >var objects = { foo: { path: "myplugin/foo"};
>> >var builder = cordova.require('cordova/builder');
>> >
>> >builder.build(objects).into(navigator);
>> >
>> >An awesome approach for plugin's would be to not to provide a platform,
>> >but
>> >more of a collection of tools (a la unix) that would make it easy for them
>> >to develop.
>> >
>> >- cordova.require and cordova.define (they can package themselves as a
>> >module and gateway to use our modules)
>> >- cordova/exec (would be nice to finally refactor out the cordova/bridge
>> >module)
>> >- cordova/utils (toolbox stuff)
>> >- cordova/builder (better API needed for building up dom namespaces, not
>> >required but there to use)
>> >
>> >
>> >
>> >On Thu, Apr 26, 2012 at 3:05 PM, Brian LeRoux <b...@brian.io> wrote:
>> >
>> >> On Wed, Apr 25, 2012 at 5:29 AM, Drew Walters <de...@gmail.com>
>> >>wrote:
>> >> > I would agree that it shouldn't be "necessary" for the addPlugin API
>> >> > (more like addNamespace), however it was nice to have during my
>> >> > development. If you look at the addPlugin API you'll notice it waits
>> >> > until DOMContentLoaded is fired so that the native browser globals
>> >> > don't overwrite the plugin. It then calls a modified builder module
>> >> > which handles overriding/merging in the various properties of the
>> >> > plugin.
>> >>
>> >> Seems like a docs issue more of an API surface issue to me.
>> >>
>> >> > Without addPlugin/mergePlugin there will certainly be repetition of
>> >> > code and greater potential for plugins to unintentionally override
>> >> > namespace of other plugins.
>> >>
>> >> could add those to util
>> >>
>> >
>> >
>> >
>> >--
>> >Gord Tanner
>> >Senior Developer / Code Poet
>> >tinyHippos Inc.
>> >@tinyhippos
>>
>>
>
>
> --
> Gord Tanner
> Senior Developer / Code Poet
> tinyHippos Inc.
> @tinyhippos
Re: Pluginization FTW
Posted by Gord Tanner <go...@tinyhippos.com>.
I would like to have a single module that holds all of the native to
javascript code.
so:
- exec
- successCallback
- errorCallback
- nativeReady stuff
kinda a one stop shop for all things native bridge like.
I don't like how it is mixed together with the cordova module right now.
cordova as a module should really just have:
require
define
On Thu, Apr 26, 2012 at 3:36 PM, Filip Maj <fi...@adobe.com> wrote:
> Love this.
>
> What is the refactor of the bridge out of exec, exactly?
>
> On 4/26/12 12:26 PM, "Gord Tanner" <go...@tinyhippos.com> wrote:
>
> >I would imagine plugins should be able to use the builder code cordova.js
> >uses to augment or extend namespaces in the dom:
> >
> >
> https://github.com/apache/incubator-cordova-js/blob/master/lib/common/comm
> >on.js
> >
> >Builder:
> >
> https://github.com/apache/incubator-cordova-js/blob/master/lib/common/buil
> >der.js
> >
> >We do need to clean this API up a bit before exposing it to the masses,
> >but
> >it would be neat if a plugin module could use this to drop objects into
> >the
> >dom:
> >
> >var objects = { foo: { path: "myplugin/foo"};
> >var builder = cordova.require('cordova/builder');
> >
> >builder.build(objects).into(navigator);
> >
> >An awesome approach for plugin's would be to not to provide a platform,
> >but
> >more of a collection of tools (a la unix) that would make it easy for them
> >to develop.
> >
> >- cordova.require and cordova.define (they can package themselves as a
> >module and gateway to use our modules)
> >- cordova/exec (would be nice to finally refactor out the cordova/bridge
> >module)
> >- cordova/utils (toolbox stuff)
> >- cordova/builder (better API needed for building up dom namespaces, not
> >required but there to use)
> >
> >
> >
> >On Thu, Apr 26, 2012 at 3:05 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> On Wed, Apr 25, 2012 at 5:29 AM, Drew Walters <de...@gmail.com>
> >>wrote:
> >> > I would agree that it shouldn't be "necessary" for the addPlugin API
> >> > (more like addNamespace), however it was nice to have during my
> >> > development. If you look at the addPlugin API you'll notice it waits
> >> > until DOMContentLoaded is fired so that the native browser globals
> >> > don't overwrite the plugin. It then calls a modified builder module
> >> > which handles overriding/merging in the various properties of the
> >> > plugin.
> >>
> >> Seems like a docs issue more of an API surface issue to me.
> >>
> >> > Without addPlugin/mergePlugin there will certainly be repetition of
> >> > code and greater potential for plugins to unintentionally override
> >> > namespace of other plugins.
> >>
> >> could add those to util
> >>
> >
> >
> >
> >--
> >Gord Tanner
> >Senior Developer / Code Poet
> >tinyHippos Inc.
> >@tinyhippos
>
>
--
Gord Tanner
Senior Developer / Code Poet
tinyHippos Inc.
@tinyhippos
Re: Pluginization FTW
Posted by Filip Maj <fi...@adobe.com>.
Love this.
What is the refactor of the bridge out of exec, exactly?
On 4/26/12 12:26 PM, "Gord Tanner" <go...@tinyhippos.com> wrote:
>I would imagine plugins should be able to use the builder code cordova.js
>uses to augment or extend namespaces in the dom:
>
>https://github.com/apache/incubator-cordova-js/blob/master/lib/common/comm
>on.js
>
>Builder:
>https://github.com/apache/incubator-cordova-js/blob/master/lib/common/buil
>der.js
>
>We do need to clean this API up a bit before exposing it to the masses,
>but
>it would be neat if a plugin module could use this to drop objects into
>the
>dom:
>
>var objects = { foo: { path: "myplugin/foo"};
>var builder = cordova.require('cordova/builder');
>
>builder.build(objects).into(navigator);
>
>An awesome approach for plugin's would be to not to provide a platform,
>but
>more of a collection of tools (a la unix) that would make it easy for them
>to develop.
>
>- cordova.require and cordova.define (they can package themselves as a
>module and gateway to use our modules)
>- cordova/exec (would be nice to finally refactor out the cordova/bridge
>module)
>- cordova/utils (toolbox stuff)
>- cordova/builder (better API needed for building up dom namespaces, not
>required but there to use)
>
>
>
>On Thu, Apr 26, 2012 at 3:05 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> On Wed, Apr 25, 2012 at 5:29 AM, Drew Walters <de...@gmail.com>
>>wrote:
>> > I would agree that it shouldn't be "necessary" for the addPlugin API
>> > (more like addNamespace), however it was nice to have during my
>> > development. If you look at the addPlugin API you'll notice it waits
>> > until DOMContentLoaded is fired so that the native browser globals
>> > don't overwrite the plugin. It then calls a modified builder module
>> > which handles overriding/merging in the various properties of the
>> > plugin.
>>
>> Seems like a docs issue more of an API surface issue to me.
>>
>> > Without addPlugin/mergePlugin there will certainly be repetition of
>> > code and greater potential for plugins to unintentionally override
>> > namespace of other plugins.
>>
>> could add those to util
>>
>
>
>
>--
>Gord Tanner
>Senior Developer / Code Poet
>tinyHippos Inc.
>@tinyhippos
Re: Pluginization FTW
Posted by Gord Tanner <go...@tinyhippos.com>.
I would imagine plugins should be able to use the builder code cordova.js
uses to augment or extend namespaces in the dom:
https://github.com/apache/incubator-cordova-js/blob/master/lib/common/common.js
Builder:
https://github.com/apache/incubator-cordova-js/blob/master/lib/common/builder.js
We do need to clean this API up a bit before exposing it to the masses, but
it would be neat if a plugin module could use this to drop objects into the
dom:
var objects = { foo: { path: "myplugin/foo"};
var builder = cordova.require('cordova/builder');
builder.build(objects).into(navigator);
An awesome approach for plugin's would be to not to provide a platform, but
more of a collection of tools (a la unix) that would make it easy for them
to develop.
- cordova.require and cordova.define (they can package themselves as a
module and gateway to use our modules)
- cordova/exec (would be nice to finally refactor out the cordova/bridge
module)
- cordova/utils (toolbox stuff)
- cordova/builder (better API needed for building up dom namespaces, not
required but there to use)
On Thu, Apr 26, 2012 at 3:05 PM, Brian LeRoux <b...@brian.io> wrote:
> On Wed, Apr 25, 2012 at 5:29 AM, Drew Walters <de...@gmail.com> wrote:
> > I would agree that it shouldn't be "necessary" for the addPlugin API
> > (more like addNamespace), however it was nice to have during my
> > development. If you look at the addPlugin API you'll notice it waits
> > until DOMContentLoaded is fired so that the native browser globals
> > don't overwrite the plugin. It then calls a modified builder module
> > which handles overriding/merging in the various properties of the
> > plugin.
>
> Seems like a docs issue more of an API surface issue to me.
>
> > Without addPlugin/mergePlugin there will certainly be repetition of
> > code and greater potential for plugins to unintentionally override
> > namespace of other plugins.
>
> could add those to util
>
--
Gord Tanner
Senior Developer / Code Poet
tinyHippos Inc.
@tinyhippos
Re: Pluginization FTW
Posted by Brian LeRoux <b...@brian.io>.
On Wed, Apr 25, 2012 at 5:29 AM, Drew Walters <de...@gmail.com> wrote:
> I would agree that it shouldn't be "necessary" for the addPlugin API
> (more like addNamespace), however it was nice to have during my
> development. If you look at the addPlugin API you'll notice it waits
> until DOMContentLoaded is fired so that the native browser globals
> don't overwrite the plugin. It then calls a modified builder module
> which handles overriding/merging in the various properties of the
> plugin.
Seems like a docs issue more of an API surface issue to me.
> Without addPlugin/mergePlugin there will certainly be repetition of
> code and greater potential for plugins to unintentionally override
> namespace of other plugins.
could add those to util
Re: Pluginization FTW
Posted by Drew Walters <de...@gmail.com>.
I would agree that it shouldn't be "necessary" for the addPlugin API
(more like addNamespace), however it was nice to have during my
development. If you look at the addPlugin API you'll notice it waits
until DOMContentLoaded is fired so that the native browser globals
don't overwrite the plugin. It then calls a modified builder module
which handles overriding/merging in the various properties of the
plugin.
Without addPlugin/mergePlugin there will certainly be repetition of
code and greater potential for plugins to unintentionally override
namespace of other plugins.
On Tue, Apr 24, 2012 at 5:42 PM, Brian LeRoux <b...@brian.io> wrote:
> +1
>
> On Tue, Apr 24, 2012 at 3:31 PM, Filip Maj <fi...@adobe.com> wrote:
>> One thing I wanted to mention: I do not think it is necessary to have an
>> "addplugin" api in JS.
>>
>> I think it should be completely up to the plugin author where and how they
>> want to attach their JS API (if it exists) to global namespaces. Should
>> not be something that the cordova framework mandates.
>>
>> The only thing we should be imposing on the JS side is, use:
>>
>> cordova.require("cordova/exec"); // reference to the exec function
>>
>> That's it. If they want to use our define+require methods, then that's
>> great, but shouldn't be necessary IMO.
>>
>> On 4/24/12 3:03 PM, "Filip Maj" <fi...@adobe.com> wrote:
>>
>>>I've had more time to go through your repo in detail, Drew, and in general
>>>love what I see. I've factored in the main points that I understood into
>>>our Plugin Design wiki article [1].
>>>
>>>Very much like your clear separation of plugins from the core framework.
>>>
>>>I think that the native side injecting the necessary js file (either for
>>>the core framework or for individual plugins) is a great feature but am
>>>skeptical this could work out in practice in a cross-platform manner.
>>>
>>>I like it a lot. I think it's a perfect fit for a framework sitting on top
>>>of the WebWorks platform.
>>>
>>>Moving forward, to get this fleshed out ASAP, need to create similar
>>>prototypes for Android, iOS and WP7, see what differences exist (if any),
>>>work out the details, formalize/document, and then set tasks for 2.0!
>>>
>>>[1] http://wiki.apache.org/cordova/PluginDesign
>>>
>>>On 4/18/12 1:58 PM, "Drew Walters" <de...@gmail.com> 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.
>>>
>>
Re: Pluginization FTW
Posted by Brian LeRoux <b...@brian.io>.
+1
On Tue, Apr 24, 2012 at 3:31 PM, Filip Maj <fi...@adobe.com> wrote:
> One thing I wanted to mention: I do not think it is necessary to have an
> "addplugin" api in JS.
>
> I think it should be completely up to the plugin author where and how they
> want to attach their JS API (if it exists) to global namespaces. Should
> not be something that the cordova framework mandates.
>
> The only thing we should be imposing on the JS side is, use:
>
> cordova.require("cordova/exec"); // reference to the exec function
>
> That's it. If they want to use our define+require methods, then that's
> great, but shouldn't be necessary IMO.
>
> On 4/24/12 3:03 PM, "Filip Maj" <fi...@adobe.com> wrote:
>
>>I've had more time to go through your repo in detail, Drew, and in general
>>love what I see. I've factored in the main points that I understood into
>>our Plugin Design wiki article [1].
>>
>>Very much like your clear separation of plugins from the core framework.
>>
>>I think that the native side injecting the necessary js file (either for
>>the core framework or for individual plugins) is a great feature but am
>>skeptical this could work out in practice in a cross-platform manner.
>>
>>I like it a lot. I think it's a perfect fit for a framework sitting on top
>>of the WebWorks platform.
>>
>>Moving forward, to get this fleshed out ASAP, need to create similar
>>prototypes for Android, iOS and WP7, see what differences exist (if any),
>>work out the details, formalize/document, and then set tasks for 2.0!
>>
>>[1] http://wiki.apache.org/cordova/PluginDesign
>>
>>On 4/18/12 1:58 PM, "Drew Walters" <de...@gmail.com> 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.
>>
>
Re: Pluginization FTW
Posted by Filip Maj <fi...@adobe.com>.
One thing I wanted to mention: I do not think it is necessary to have an
"addplugin" api in JS.
I think it should be completely up to the plugin author where and how they
want to attach their JS API (if it exists) to global namespaces. Should
not be something that the cordova framework mandates.
The only thing we should be imposing on the JS side is, use:
cordova.require("cordova/exec"); // reference to the exec function
That's it. If they want to use our define+require methods, then that's
great, but shouldn't be necessary IMO.
On 4/24/12 3:03 PM, "Filip Maj" <fi...@adobe.com> wrote:
>I've had more time to go through your repo in detail, Drew, and in general
>love what I see. I've factored in the main points that I understood into
>our Plugin Design wiki article [1].
>
>Very much like your clear separation of plugins from the core framework.
>
>I think that the native side injecting the necessary js file (either for
>the core framework or for individual plugins) is a great feature but am
>skeptical this could work out in practice in a cross-platform manner.
>
>I like it a lot. I think it's a perfect fit for a framework sitting on top
>of the WebWorks platform.
>
>Moving forward, to get this fleshed out ASAP, need to create similar
>prototypes for Android, iOS and WP7, see what differences exist (if any),
>work out the details, formalize/document, and then set tasks for 2.0!
>
>[1] http://wiki.apache.org/cordova/PluginDesign
>
>On 4/18/12 1:58 PM, "Drew Walters" <de...@gmail.com> 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.
>
Re: Pluginization FTW
Posted by Filip Maj <fi...@adobe.com>.
I've had more time to go through your repo in detail, Drew, and in general
love what I see. I've factored in the main points that I understood into
our Plugin Design wiki article [1].
Very much like your clear separation of plugins from the core framework.
I think that the native side injecting the necessary js file (either for
the core framework or for individual plugins) is a great feature but am
skeptical this could work out in practice in a cross-platform manner.
I like it a lot. I think it's a perfect fit for a framework sitting on top
of the WebWorks platform.
Moving forward, to get this fleshed out ASAP, need to create similar
prototypes for Android, iOS and WP7, see what differences exist (if any),
work out the details, formalize/document, and then set tasks for 2.0!
[1] http://wiki.apache.org/cordova/PluginDesign
On 4/18/12 1:58 PM, "Drew Walters" <de...@gmail.com> 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.