Hey Fil,
Please let me know if I can help with anything.
--
Gorkem
On Tue, Apr 9, 2013 at 12:18 PM, Filip Maj wrote:
> Hey Gorkem,
>
> There is a bunch of housework to do around merging the PR. Thank you for
> providing two implementations, but we have to be sure that all other
> platforms at l
If it's going to be actually removed in 2.7, I would suggest that we should
put a notice to that affect--immediately--in the 2.6 docs.
It looks like that wording has been there since the 2.1 docs, so developers
have certainly been warned for some time. On the other hand, keeping the
deprecation no
It's deprecated, see "Deprecated Plugin Signature Note":
http://docs.phonegap.com/en/2.6.0/guide_plugin-development_ios_index.md.html#Developing%20a%20Plugin%20on%20iOS
... although I don't think we print out a notice currently.
I propose that we remove it for the next version, it's definitely mo
Hello,
Any reason why we keep on supporting the old exec signature on iOS ? [1]
[1]
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=blob;f=lib/ios/exec.js;h=5e237d968cb948438fc92694d9288d72c9c3a7ac;hb=125dca530923a44a8f44f68f5e1970cbdd4e7faf#l132
-a
After chatting with Anis on IRC I think I understand your point a bit
better with respect to plugin vs. app permissions.
I believe our move from to in an application's
config.xml should solve this issue. That is, if the application developer
explicitly lists out permissions they deem as necessar
Perfect, lets roll with this for now then.
Next step: write tests for plugman. We're getting closer..
On 4/17/13 4:16 PM, "Jesse" wrote:
>Yes, element would work fine for wp7+8 as well.
>I then see no other need for the element.
>
>parent="/Deployment/App/Capabilities">
>
>
>
Yes, element would work fine for wp7+8 as well.
I then see no other need for the element.
@purplecabbage
risingj.com
On Wed, Apr 17, 2013 at 4:04 PM, Filip Maj wrote:
> Nope nothing being forced on anyone here. I agree with you: developers
> should be aware of the pla
Nope nothing being forced on anyone here. I agree with you: developers
should be aware of the platforms they are targeting and should understand
how their app works, regardless if its written with a cross-platform
framework or not.
We are talking about a spec helping standardize the way bits of
fu
The use case is any app that has any additional native functionality added
by the developer. ( every app I have ever written )
Otherwise we force an all or nothing stance with cordova use, Android,
iOS, wp7, wp8 all support using cordova as a view in an otherwise strictly
native app, or adding a n
>However, I do not think that removing permissions will end well. Looking
>at the bigger picture, I can think of many cases where a permission is
>required by the app itself, and should remain regardless of any plugin.
> This needs to be decided by the app developer themselves imho.
Can you prov
This is a good point. Might be better to warn about unused permissions.
(And offer an audit command for cleanup/release purposes.)
On Wed, Apr 17, 2013 at 3:13 PM, Jesse wrote:
> I think we do have consensus on , you can ignore the entire
> discussion of as it is up to the app developer to 'req
I think we do have consensus on , you can ignore the entire
discussion of as it is up to the app developer to 'require'
and not the plugin developer.
However, I do not think that removing permissions will end well. Looking
at the bigger picture, I can think of many cases where a permission is
re
>Is it possible to re-do the platform modifications on every `cordova
>prepare` by running through each plugin.xml? That way, on uninstall you
>needn't do anything, just remove the plugin and run prepare again. This
>would also make it possible to make changes to a plugin's native code
>without
On Wed, Apr 17, 2013 at 5:44 PM, Michal Mocny wrote:
> Is it possible to re-do the platform modifications on every `cordova
> prepare` by running through each plugin.xml? That way, on uninstall you
> needn't do anything, just remove the plugin and run prepare again. This
> would also make it po
Is it possible to re-do the platform modifications on every `cordova
prepare` by running through each plugin.xml? That way, on uninstall you
needn't do anything, just remove the plugin and run prepare again. This
would also make it possible to make changes to a plugin's native code
without reinst
K I will hold off on until we come to a consensus. You're
right in that we could put it in as a child to .. Duplication
can be easily prevented (check if permission exists already before adding
it).
Removing config-file stuff during a plugin uninstall is trickier.. If two
plugins depend on the sa
On Wed, Apr 17, 2013 at 2:07 PM, Michal Mocny wrote:
> To add a few more thoughts RE: URL to find plugin universe:
>
> - We could also support an apt style model where the user has a personal
> global list of repositories specified, and the tools use that list to find
> plugins referenced by name
On Wed, Apr 17, 2013 at 9:59 AM, Filip Maj wrote:
> Max, yeah, at the top of the plugman readme (in both future and master I
> believe), the usage docs don't specify --install or --uninstall as an
> available command, but those commands are referenced right after the usage
> section. I'd be in fa
To add a few more thoughts RE: URL to find plugin universe:
- We could also support an apt style model where the user has a personal
global list of repositories specified, and the tools use that list to find
plugins referenced by name, starting with a single default (or a
cordova-core universe and
Good point Don, the requirements should be out of scope for a plugin
developer.
I agree that ultimately this is a choice that the developer should make for
their own app.
@purplecabbage
risingj.com
On Wed, Apr 17, 2013 at 1:22 PM, Don Coleman wrote:
> On Windows Phone the permission required t
On Wed, Apr 17, 2013 at 2:50 PM, Joe Bowser wrote:
> So, there isn't a CORS issue with Android?
>
>
I can neither confirm nor deny the existence of the alleged CORS issue on
Android :)
I'll probably know more about that tomorrow; I'll let you know what I find.
If we're using OkHttp, though, we
+1
On Wed, Apr 17, 2013 at 1:20 PM, Jeffrey Heifetz wrote:
> +1
>
> On 13-04-17 4:14 PM, "Joe Bowser" wrote:
>
> >+1 for deprecate now, remove 3.0
> >
> >On Wed, Apr 17, 2013 at 12:15 PM, Shazron wrote:
> >> +1 for deprecate now, remove 3.0
> >>
> >>
> >> On Wed, Apr 17, 2013 at 10:00 AM, Fili
Thanks for the details Ian.
In our experience, by-passing CORS policies is a HUGE bonus for most
developers. It would be rad if you can find a nice hackity-hack to get
around this so that we can also take advantage of WebSQL :)
Michael
On Wed, Apr 17, 2013 at 12:50 PM, Joe Bowser wrote:
> So,
On Windows Phone the permission required to access NFC is ID_CAP_PROXIMITY.
The ID_REQ_NFC restricts the application to running on only devices that
have NFC.
This would be equivalent to setting android:required to true for a feature
AFAIK android:required="true" only effects Google Play l
+1
On 13-04-17 4:14 PM, "Joe Bowser" wrote:
>+1 for deprecate now, remove 3.0
>
>On Wed, Apr 17, 2013 at 12:15 PM, Shazron wrote:
>> +1 for deprecate now, remove 3.0
>>
>>
>> On Wed, Apr 17, 2013 at 10:00 AM, Filip Maj wrote:
>>
>>> My vote is to set up deprecation of plugin now, and remove it
+1 for deprecate now, remove 3.0
On Wed, Apr 17, 2013 at 12:15 PM, Shazron wrote:
> +1 for deprecate now, remove 3.0
>
>
> On Wed, Apr 17, 2013 at 10:00 AM, Filip Maj wrote:
>
>> My vote is to set up deprecation of plugin now, and remove it completely
>> for 3.0. Our tooling should be able to ha
I could, or it could just be an ignored tag for other platforms. It will
sit inside the platform tag anyway.
could also just add an optional attrib to the permission tag :
The names already do contain enough info to easily parse, ID_CAP_* ID_REQ_*
not to mention ID_RESOLUTION_*
I am down with wh
Hmm, this could be an implementation detail for windows phone.
Requirement vs permission isn't syntactically different. Could we
encapsulate Windows Phone requirements as elements in
plugin.xml, and have tooling be smart enough to parse wp7 + wp8
elements and drop them into the Windows Phone ma
While we are there, we may want to add an optional requirements tag.
Requirements let the app specify what device features it must have, for
example NFC. [1]
Logically this would just fall right under platform, and be optional :
Does it make sense for us to group these?
ie.
+1 for deprecate now, remove 3.0
On Wed, Apr 17, 2013 at 10:00 AM, Filip Maj wrote:
> My vote is to set up deprecation of plugin now, and remove it completely
> for 3.0. Our tooling should be able to handle this stuff by then..
>
> On 4/16/13 8:23 PM, "Joe Bowser" wrote:
>
> >Only when we deci
Good call, sound rule of thumb
On 4/17/13 12:03 PM, "Jesse" wrote:
>RE: the permission element
>Looks good for wp7 + wp8
>I assume if some platform requires extra data in the permission tag it can
>have it, the same way that the blackberry version has the system
>attribute.
>
>@purplecabbage
>ri
RE: the permission element
Looks good for wp7 + wp8
I assume if some platform requires extra data in the permission tag it can
have it, the same way that the blackberry version has the system attribute.
@purplecabbage
risingj.com
On Wed, Apr 17, 2013 at 11:48 AM, Jeffrey Heifetz
wrote:
> Makes
So, there isn't a CORS issue with Android?
On Wed, Apr 17, 2013 at 11:41 AM, Ian Clelland wrote:
> Specifically with iOS, setting the start page to a chrome-extension:// url
> causes the underlying UIWebView to apply CORS policies to all XHR requests.
>
> UIWebView seems to use the same restricti
Specifically with iOS, setting the start page to a chrome-extension:// url
causes the underlying UIWebView to apply CORS policies to all XHR requests.
UIWebView seems to use the same restrictions as desktop Safari:
- Requests coming from file:/// urls do not use the Origin header
- Requests
Makes sense to me.
Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Filip Maj
Sent: Wednesday, April 17, 2013 2:43 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: plugman + plugin spec final q's
K one more update: element that will be a child of
el
K one more update: element that will be a child of
elements.
Examples:
`name` attribute is mandatory, mapping to native strings representing
specific features/permissions.
`system` attribute is optional and false by default. Only used b
Thanks Jukka,
Added the committers from the list plus any Apache members
On Wed, Apr 17, 2013 at 11:20 AM, Jukka Zitting wrote:
> Hi,
>
> On Wed, Apr 17, 2013 at 6:54 PM, Shazron wrote:
> > Done. As a general rule, I'm adding all committers in the AdminGroup,
> > non-committers in the Contribut
Hi,
On Wed, Apr 17, 2013 at 6:54 PM, Shazron wrote:
> Done. As a general rule, I'm adding all committers in the AdminGroup,
> non-committers in the ContributorsGroup. Unfortunately I can't find a full
> list of people signed up to the wiki (yet) [...]
See below for a list of all accounts who've
bennmapes
On Wed, Apr 17, 2013 at 10:37 AM, Michal Mocny wrote:
> mmocny
>
>
> On Wed, Apr 17, 2013 at 1:34 PM, Simon MacDonald
> wrote:
>
> > Username = SimonMacDonald
> > Simon Mac Donald
> > http://hi.im/simonmacdonald
> >
> >
> > On Wed, Apr 17, 2013 at 1:25 PM, James Jong
> wrote:
> > > u
I was thinking exactly along the same lines as Braden. Whatever universe
the cordova core plugins live in will likely be default, with the wild
west following it. SO long as plugman is explicit about where it is
fetching from, a dev shouldn't have to find the URL and hope it never
changes.
On 13-0
Kay ill update the spec
On 4/17/13 11:01 AM, "Braden Shepherdson" wrote:
>I think there will be a common repo, where the Cordova core plugins and
>some others live. See the spec for the remotes.js file; I think it should
>search for plugins with the given name in each of those universes.
>Specif
I think there will be a common repo, where the Cordova core plugins and
some others live. See the spec for the remotes.js file; I think it should
search for plugins with the given name in each of those universes.
Specifying a url in the would then only be necessary for other
universes.
Braden
O
But then we'd need to be able to discover the different universes.. Unless
we all agree on a "default", don't think this is optional..
On 4/17/13 10:53 AM, "Jeffrey Heifetz" wrote:
>Coming back to Braden's suggestion of specifying a url and id for plugin
>dependency, I think this is the correct
Coming back to Braden's suggestion of specifying a url and id for plugin
dependency, I think this is the correct route, and would go further to
suggest the url is optional. I do not believe we should inherently tie
plugin dependency to the exact source. Thats why we have a discovery
system and mult
mmocny
On Wed, Apr 17, 2013 at 1:34 PM, Simon MacDonald
wrote:
> Username = SimonMacDonald
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Wed, Apr 17, 2013 at 1:25 PM, James Jong wrote:
> > username JamesJong
> >
> > On Apr 17, 2013, at 11:54 AM, Shazron wrote:
> >
> >> Done. As a g
Braden and I had a little chat on IRC about install/uninstall and calling
prepare. We've agreed that having prepare as a separate command is useful
(you tweak some plugin JS files, add more JS files, and want that
reflected in your app), but also calling prepare automatically after an
install and u
Username = SimonMacDonald
Simon Mac Donald
http://hi.im/simonmacdonald
On Wed, Apr 17, 2013 at 1:25 PM, James Jong wrote:
> username JamesJong
>
> On Apr 17, 2013, at 11:54 AM, Shazron wrote:
>
>> Done. As a general rule, I'm adding all committers in the AdminGroup,
>> non-committers in the Con
Ian has been running into some issues with CORS while working on porting an
app, I'll let him comment on specifics.
On Wed, Apr 17, 2013 at 12:27 PM, Michael Brooks
wrote:
> Very cool Andrew. Does this affect the cross-origin policy? Many users
> exploit the ability to make requests across multi
Actually, Andrew suggested a better alternative. I'll just modify the
AppDelegate to #ifdef the few lines of offending code to do the right thing
regardless of arc settings.
On Tue, Apr 16, 2013 at 2:52 PM, Filip Maj wrote:
> Maybe toss that into the release article on the wiki so we have a pa
In my mind that is certainly an objective, Brian.
On 4/17/13 10:25 AM, "Brian LeRoux" wrote:
>Braden: you thinking that the config is canonical and then prepare quietly
>does the right thing based on that?
>
>(Agree less steps is exactly what we're going for here.)
>
>
>On Wed, Apr 17, 2013 at 1
username JamesJong
On Apr 17, 2013, at 11:54 AM, Shazron wrote:
> Done. As a general rule, I'm adding all committers in the AdminGroup,
> non-committers in the ContributorsGroup. Unfortunately I can't find a full
> list of people signed up to the wiki (yet) so I can bulk add, so you'll
> have to
Braden: you thinking that the config is canonical and then prepare quietly
does the right thing based on that?
(Agree less steps is exactly what we're going for here.)
On Wed, Apr 17, 2013 at 10:16 AM, Braden Shepherdson wrote:
> Re: --install calling --prepare: no. It could, though, I suppose.
Re: --install calling --prepare: no. It could, though, I suppose.
Why not have --prepare handle the plugins rather than install/remove. We're
trying to make less, not more, happen at install time. Someday I hope
--install ceases to exist.
On Wed, Apr 17, 2013 at 12:59 PM, Filip Maj wrote:
> Ma
My vote is to set up deprecation of plugin now, and remove it completely
for 3.0. Our tooling should be able to handle this stuff by then..
On 4/16/13 8:23 PM, "Joe Bowser" wrote:
>Only when we decide to drop plugin.
>On Apr 16, 2013 8:14 PM, "Filip Maj" wrote:
>
>> https://issues.apache.org/ji
Max, yeah, at the top of the plugman readme (in both future and master I
believe), the usage docs don't specify --install or --uninstall as an
available command, but those commands are referenced right after the usage
section. I'd be in favor of using --fetch for the RETRIEVAL of plugins,
--remove
I'm not convinced you need any additional code here.
Touch events are already fired by the web view containers. You could build
up gesture detection in JavaScript by listening to these events.
There are libraries out there that do this for you already:
- http://eightmedia.github.io/hammer.js/
This is an interesting idea. I know we get many requests for gesture
recognition on BlackBerry 10. Adding the link below as references as well for
the BB platform :)
https://developer.blackberry.com/native/reference/bb10/com.qnx.doc.gestures.lib_ref/topic/overview.html
-Erik
___
I'm experimenting with Cordova on Android, iOS and Windows 8.
Has there been a discussion around trying to implement to set of 'standard'
gesture recognizers:
http://msdn.microsoft.com/library/windows/apps/BR241937
http://developer.apple.com/library/ios/#documentation/EventHandling/Conceptual/Ev
(1) On line 25 of the cordova-plugman readme, is the command missing (ie.
--add or --install or whatever)?
(2) Though two versions of a plugin are not allowed, I just want to make
sure: there will be some kind of detection that it's okay if the
*same*version of a plugin has already been installed
Very cool Andrew. Does this affect the cross-origin policy? Many users
exploit the ability to make requests across multiple domains.
Michael
On Wed, Apr 17, 2013 at 8:35 AM, Andrew Grieve wrote:
> Just tried it with:
>
> chrome-extension://asdf/chromeapp.html?foo:1?#asdf?ds#af:s
>
> Had to mak
Responses inline.
On Wed, Apr 17, 2013 at 3:08 AM, Filip Maj wrote:
> Hey all,
>
> I've done a review of the spec and updated it. Check it out at the README
> in the plugman repo's future branch [1]. I've added the last bit to it:
> and elements. Here is an example:
>
>
> url="h
Done. As a general rule, I'm adding all committers in the AdminGroup,
non-committers in the ContributorsGroup. Unfortunately I can't find a full
list of people signed up to the wiki (yet) so I can bulk add, so you'll
have to still post here with your wiki username for access... (which kinda
authent
Just tried it with:
chrome-extension://asdf/chromeapp.html?foo:1?#asdf?ds#af:s
Had to make a slight tweak to IceCreamCordovaWebViewClient, but it worked
fine.
On Wed, Apr 17, 2013 at 12:39 AM, Joe Bowser wrote:
> How does this affect URI handling? We've had far bigger issues with
> file:///a
Account name is "Braden Shepherdson"
On Tue, Apr 16, 2013 at 6:17 PM, Michael Brooks wrote:
> Yep I can edit, thanks Shaz!
>
>
> On Tue, Apr 16, 2013 at 3:14 PM, Brian LeRoux wrote:
>
> > ya no kidding
> >
> >
> > On Tue, Apr 16, 2013 at 2:46 PM, Anis KADRI
> wrote:
> >
> > > That's cool! I wa
Late to the party but...
+1 for dropping support for 2.2
Simon Mac Donald
http://hi.im/simonmacdonald
On Wed, Apr 17, 2013 at 9:53 AM, James Jong wrote:
> Deprecation in 2.7?
>
> -James Jong
>
> On Apr 15, 2013, at 1:27 PM, Filip Maj wrote:
>
>> Looks like we have consensus
>>
>> Joe is going
Deprecation in 2.7?
-James Jong
On Apr 15, 2013, at 1:27 PM, Filip Maj wrote:
> Looks like we have consensus
>
> Joe is going to be happy :)
>
> On 4/15/13 10:24 AM, "Andrew Grieve" wrote:
>
>> +1 DROP!
>>
>>
>> On Wed, Apr 10, 2013 at 6:04 PM, Shazron wrote:
>>
>>> My Nexus One latest
I like this idea, the user might be confused if nothing happens if a plugin
isn't compatible.
+ 1 for a Warning
On Apr 16, 2013, at 5:29 PM, Anis KADRI wrote:
> I like fil's proposal. Either way, I don't think it should be an error, it
> should just be a warning. If if it's an error then when
Hey all,
I've done a review of the spec and updated it. Check it out at the README
in the plugman repo's future branch [1]. I've added the last bit to it:
and elements. Here is an example:
http://plugins.cordova.io/com.facebook.plugin/plugin.xml"; />
http://plugins.phonegap
68 matches
Mail list logo
