I'm cool w/ window.cordova.plugins (or is it window.Cordova.plugins?)
Don't think we should prescribe anything for 3rd party plugins but
encourage namespaced behavior as jesse suggests.
On Thu, Feb 7, 2013 at 2:00 PM, Anis KADRI wrote:
> I agree with window.plugins for everything that is not a p
I agree with window.plugins for everything that is not a polyfill.
On Thu, Feb 7, 2013 at 12:43 PM, Filip Maj wrote:
> Agree with everything Jesse said. cordova.plugins could be considered
> "safe", but not required. It's just JavaScript!
>
> On 2/6/13 6:27 PM, "Jesse" wrote:
>
> >> I would pr
Agree with everything Jesse said. cordova.plugins could be considered
"safe", but not required. It's just JavaScript!
On 2/6/13 6:27 PM, "Jesse" wrote:
>> I would prefer cordova.plugins instead of directly on cordova.
>+1
>
>I agree, and like having core plugins live under cordova.plugins.*, bu
On Wed, Feb 6, 2013 at 9:27 PM, Jesse wrote:
> > I would prefer cordova.plugins instead of directly on cordova.
> +1
>
> I agree, and like having core plugins live under cordova.plugins.*, but I
> don't think this should be a requirement of other plugins.
>
required, no, but I wonder if we canno
> I would prefer cordova.plugins instead of directly on cordova.
+1
I agree, and like having core plugins live under cordova.plugins.*, but I
don't think this should be a requirement of other plugins.
For example: com.dropbox.session.startAuthentication(this);
makes sense to me
In the end, anyon
I agree with Michal that hanging things off the cordova object can get
pretty unmanageable after a while, and having it namespaced under
cordova.plugins or something similar would be better.
InAppBrowser is a weird one since window.open will work in browsers, but
not everything it supports is supp
I like the proposal, and do think our extensions should be namespaced.
However, your one example of InAppBrowser is debatable if it is a polyfill
or extension, and has good arguments for either side. So, perhaps we can
leave that example (or any other specific plugin) aside, and focus on the
over
Some of our APIs are meant to be polyfills, and some of them are not.
It's great to expose the polyfill-type ones using the standards-based
symbols. E.g. FileEntry, requestFileSystem.
For the custom ones though, I think it's important for devs to realize that
the APIs they are using are custom to
