date:20150211

RE: ArrayBuffers in WP8 Plugins

2015-02-11 Thread Sergey Grebnov (Akvelon)

Another two examples examples:
https://github.com/sgrebnov/BluetoothSerial/blob/master/src/wp/Bluetooth.cs#L549
 
Listbyte data = JsonHelper.DeserializeListbyte(args[0]);
..
dataWriter.WriteBytes(data.ToArray())

https://github.com/apache/cordova-plugin-file/blob/master/src/wp/File.cs#L884
byte[] dataToWrite = isBinary ? JSON.JsonHelper.Deserializebyte[](data) :
 System.Text.Encoding.UTF8.GetBytes(data);

Thx!
Sergey
-Original Message-
From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of Ian 
Clelland
Sent: Wednesday, February 11, 2015 6:37 PM
To: dev@cordova.apache.org
Subject: Re: ArrayBuffers in WP8 Plugins

The File plugin should have that -- spec test 104 tests calling
FileWriter.write() with an ArrayBuffer as an argument.

The write() method in File.cs looks like it uses JSON.JsonHelper.Deserialize to 
deserialize it, though -- you might have to dig into the bridge to see exactly 
how and where it gets encoded in the first place.


On Tue, Feb 10, 2015 at 8:28 PM, Don Coleman don.cole...@gmail.com wrote:

 Are there any examples of deserializing arraybuffers in WP8 plugins?

 I'm looking for the WP8 equivalent of Android's byte[] data = args.
 getArrayBuffer(3);

Schedule for npm transition

2015-02-11 Thread Gorkem Ercan



Is there a determined calendar for the npm move of the plugins?
I think the scheduling of the transition is crucial for those who are 
using the plugin registry directly.

--
Gorkem

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Schedule for npm transition

2015-02-11 Thread Steven Gill

We don't have one yet but we should pick dates soon.

How about:

CPR Switch to read only: Monday, May 18th
NPM fetch becomes default: Monday, May 18th
CPR offline: Monday, August 17th

Based on the following proposal:
https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing

 - Need to start educating plugin developers to publish to npm as well as
CPR for next three months. (blog post)
 - Need to educate users to install plugins via new names (if package-name
is different than id). Our core plugins are being renamed from
org.apache.cordova.device to cordova-plugin-device
- Inform devs who are working with registry directly to pull plugins from
npm instead of CPR. After 3 months, CPR plugins will start to become out of
date compared to npm versions.

Our next plugins release (after the one currently ongoing) will be
published to npm as well as cpr.



On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan gorkem.er...@gmail.com
wrote:


 Is there a determined calendar for the npm move of the plugins?
 I think the scheduling of the transition is crucial for those who are
 using the plugin registry directly.
 --
 Gorkem

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Schedule for npm transition

2015-02-11 Thread Michal Mocny

Steve, npm fetch default only affects plugins that use same name in both
places, right?

If we create cordova-plugin-device today, and tell users to start using
cordova plugin add cordova-plugin-device, then we will get much user
feedback on npm fetching far before May 18th, right?

On Wed, Feb 11, 2015 at 1:09 PM, Steven Gill stevengil...@gmail.com wrote:

 We don't have one yet but we should pick dates soon.

 How about:

 CPR Switch to read only: Monday, May 18th
 NPM fetch becomes default: Monday, May 18th
 CPR offline: Monday, August 17th

 Based on the following proposal:

 https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing

  - Need to start educating plugin developers to publish to npm as well as
 CPR for next three months. (blog post)
  - Need to educate users to install plugins via new names (if package-name
 is different than id). Our core plugins are being renamed from
 org.apache.cordova.device to cordova-plugin-device
 - Inform devs who are working with registry directly to pull plugins from
 npm instead of CPR. After 3 months, CPR plugins will start to become out of
 date compared to npm versions.

 Our next plugins release (after the one currently ongoing) will be
 published to npm as well as cpr.



 On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan gorkem.er...@gmail.com
 wrote:

 
  Is there a determined calendar for the npm move of the plugins?
  I think the scheduling of the transition is crucial for those who are
  using the plugin registry directly.
  --
  Gorkem
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Schedule for npm transition

2015-02-11 Thread Steven Gill

Correct! For the first 3 months, all requests will hit CPR first, if CPR
fails, we will try to fetch from npm.

If users run cordova plugin add cordova-plugin-device, it would hit CPR,
fail, go to npm, succeed.

If we use the mapper module, cordova plugin add
org.apache.cordova.device would be converted to cordova-plugin-device, hit
CPR, fail, go to npm, succeed.

After 3 months, cordova plugin add cordova-plugin-device would hit npm
first and succeed.

We want to use these 3 months to get our developers to update their tools
and use the new names for plugins to install.

On Wed, Feb 11, 2015 at 10:36 AM, Michal Mocny mmo...@chromium.org wrote:

Steve, npm fetch default only affects plugins that use same name in both
places, right?

If we create cordova-plugin-device today, and tell users to start using
cordova plugin add cordova-plugin-device, then we will get much user
feedback on npm fetching far before May 18th, right?

On Wed, Feb 11, 2015 at 1:09 PM, Steven Gill stevengil...@gmail.com
wrote:

We don't have one yet but we should pick dates soon.

How about:

CPR Switch to read only: Monday, May 18th
NPM fetch becomes default: Monday, May 18th
CPR offline: Monday, August 17th

Based on the following proposal:

https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing

- Need to start educating plugin developers to publish to npm as well as
CPR for next three months. (blog post)
- Need to educate users to install plugins via new names (if
package-name
is different than id). Our core plugins are being renamed from
org.apache.cordova.device to cordova-plugin-device
- Inform devs who are working with registry directly to pull plugins from
npm instead of CPR. After 3 months, CPR plugins will start to become out
of
date compared to npm versions.

Our next plugins release (after the one currently ongoing) will be
published to npm as well as cpr.

On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan gorkem.er...@gmail.com
wrote:

Is there a determined calendar for the npm move of the plugins?
I think the scheduling of the transition is crucial for those who are
using the plugin registry directly.
--
Gorkem

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: ArrayBuffers in WP8 Plugins

2015-02-11 Thread Ian Clelland

The File plugin should have that -- spec test 104 tests calling
FileWriter.write() with an ArrayBuffer as an argument.

The write() method in File.cs looks like it uses
JSON.JsonHelper.Deserialize to deserialize it, though -- you might have to
dig into the bridge to see exactly how and where it gets encoded in the
first place.


On Tue, Feb 10, 2015 at 8:28 PM, Don Coleman don.cole...@gmail.com wrote:

 Are there any examples of deserializing arraybuffers in WP8 plugins?

 I'm looking for the WP8 equivalent of Android's byte[] data = args.
 getArrayBuffer(3);

[GitHub] cordova-lib pull request: CB-8420 'cordova plugin add' should retr...

2015-02-11 Thread agrieve

Github user agrieve commented on a diff in the pull request:

https://github.com/apache/cordova-lib/pull/162#discussion_r24500705
  
--- Diff: cordova-lib/src/cordova/plugin.js ---
@@ -114,6 +116,22 @@ module.exports = function plugin(command, targets, 
opts) {
 target = target.substring(0, target.length - 
1);
 }
 
+var parts = target.split('@');
+var id = parts[0];
+var version = parts[1];
+
+// If no version is specified, retrieve the 
version from config.xml
+if(!version  !cordova_util.isUrl(id)  
!cordova_util.isDirectory(id)){
+events.emit('verbose', 'no version specified, 
retrieving version from config.xml');
+var ver = getVersionFromConfigFile(id, cfg);
+
+if( cordova_util.isUrl(ver) || 
cordova_util.isDirectory(ver) ){
--- End diff --

isDirectory don't check for null/undefined. Should either add that to 
isDirectory, or add check here.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-lib pull request: CB-8420 'cordova plugin add' should retr...

2015-02-11 Thread agrieve

Github user agrieve commented on the pull request:

https://github.com/apache/cordova-lib/pull/162#issuecomment-73895354
  
lgtm save one nit. I think this behaviour is fine. Normal case will be to 
use add --save anyways.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] Plugins Release

2015-02-11 Thread Andrew Grieve

Just checked - link is working again. Please cast some votes :)

On Mon, Feb 9, 2015 at 1:55 PM, Andrew Grieve agri...@chromium.org wrote:

 I can't even svn up on it right now. Think it's just having an outage.

 On Mon, Feb 9, 2015 at 11:19 AM, Alexander Sorokin (Akvelon) 
 v-als...@microsoft.com wrote:

 Hi guys,

 It looks like there is something wrong with access rules or something.
 I cannot access https://dist.apache.org/repos/dist/dev/cordova/CB-8429/
 It says: 403 Forbidden
 Can someone open access to it?

 Thanks,
 Alexander Sorokin

 -Original Message-
 From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
 Grieve
 Sent: Monday, February 9, 2015 18:05
 To: dev
 Subject: [VOTE] Plugins Release

 Please review and vote on the release of this plugins release.

 Release issue: https://issues.apache.org/jira/browse/CB-8429 (contains
 release notes for all plugins)

 The plugins have been published to dist/dev:
 https://dist.apache.org/repos/dist/dev/cordova/CB-8429/

 They are the same as last week except for file-transfer.

 The packages were published from their corresponding git tags:

 cordova-plugin-battery-status: 0.2.12 (ec59ef11a5)
 cordova-plugin-camera: 0.3.5 (799ed580d3)
 cordova-plugin-console: 0.2.13 (7507b29527)
 cordova-plugin-contacts: 0.2.16 (95d4d176f3)
 cordova-plugin-device-motion: 0.2.11 (110b27671f)
 cordova-plugin-device-orientation: 0.3.11 (d8fd79b2ae)
 cordova-plugin-device: 0.3.0 (4330db87b9)
 cordova-plugin-dialogs: 0.3.0 (d12008f9cd)
 cordova-plugin-file-transfer: 0.5.0 (1882bfbd2d)
 cordova-plugin-file: 1.3.3 (b05bcff378)
 cordova-plugin-geolocation: 0.3.12 (ccab812a49)
 cordova-plugin-globalization: 0.3.4 (6b1e88d534)
 cordova-plugin-inappbrowser: 0.6.0 (90d41e87ce)
 cordova-plugin-media: 0.2.16 (10df21dea8)
 cordova-plugin-media-capture: 0.3.6 (cc779375e3)
 cordova-plugin-network-information: 0.2.15 (81037e29cf)
 cordova-plugin-splashscreen: 1.0.0 (a9f0faa499)
 cordova-plugin-vibration: 0.3.13 (25217db403)
 cordova-plugin-statusbar: 0.1.10 (5feffc9314)
 cordova-plugins: file-system-roots-0.1.0 (be0a4c6cfb)
 cordova-plugin-test-framework: 0.0.1 (6aad294699)


 Upon a successful vote I will upload the archives to dist/, upload them
 to the Plugins Registry, and post the corresponding blog post.

 Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

 Voting will go on for a minimum of 24 hours.

 I vote +1:

 * Ran coho audit-license-headers over the relevant repos
 * Ran coho check-license to ensure all dependencies and subdependencies
 have Apache-compatible licenses
 * Ran mobile-spec on android, and made sure it compiled for iOS. There
 were only 2 failures in media, and I verified that the same 2 errors happen
 with the previous plugin version

Re: Schedule for npm transition

2015-02-11 Thread Andrew Grieve

Going to try and summarize my concerns with the proposal here:

On Wed, Feb 11, 2015 at 2:39 PM, Steven Gill stevengil...@gmail.com wrote:

Correct! For the first 3 months, all requests will hit CPR first, if CPR
fails, we will try to fetch from npm.

If users run cordova plugin add cordova-plugin-device, it would hit CPR,
fail, go to npm, succeed.

CPR doesn't allow non-reverse dns names. There'd be no reason to check it
unless the name had at least 2 periods in it.

If we're not using package names to detect which registry to use, I don't
actually see any benefit in changing names.

If we use the mapper module, cordova plugin add
org.apache.cordova.device would be converted to cordova-plugin-device, hit
CPR, fail, go to npm, succeed.

While this works fine for our modules, I don't think it'll work well for
others'. Three use-cases for them:
1. dependency within plugin.xml.
2. plugin within config.xml (for cordova plugin restore).
3. cordova plugin add FOO

All three would be solved if we enforce that packageName == pluginId.

I think we should either:
- publish under npm under our existing IDs
or:
- publish under npm under cordova-plugin-FOO, and change plugin IDs to be
cordova-plugin-FOO

After 3 months, cordova plugin add cordova-plugin-device would hit npm
first and succeed.

We want to use these 3 months to get our developers to update their tools
and use the new names for plugins to install.

On Wed, Feb 11, 2015 at 10:36 AM, Michal Mocny mmo...@chromium.org
wrote:

Steve, npm fetch default only affects plugins that use same name in both
places, right?

If we create cordova-plugin-device today, and tell users to start using
cordova plugin add cordova-plugin-device, then we will get much user
feedback on npm fetching far before May 18th, right?

On Wed, Feb 11, 2015 at 1:09 PM, Steven Gill stevengil...@gmail.com
wrote:

We don't have one yet but we should pick dates soon.

How about:

CPR Switch to read only: Monday, May 18th
NPM fetch becomes default: Monday, May 18th
CPR offline: Monday, August 17th

Based on the following proposal:

https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing

- Need to start educating plugin developers to publish to npm as well
as
CPR for next three months. (blog post)
- Need to educate users to install plugins via new names (if
package-name
is different than id). Our core plugins are being renamed from
org.apache.cordova.device to cordova-plugin-device
- Inform devs who are working with registry directly to pull plugins
from
npm instead of CPR. After 3 months, CPR plugins will start to become
out
of
date compared to npm versions.

Our next plugins release (after the one currently ongoing) will be
published to npm as well as cpr.

On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan gorkem.er...@gmail.com
wrote:

Is there a determined calendar for the npm move of the plugins?
I think the scheduling of the transition is crucial for those who are
using the plugin registry directly.
--
Gorkem

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

RE: Schedule for npm transition

2015-02-11 Thread Treggiari, Leo

The proposal contains suggestions, alternatives and comments.

 https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing

When will there be a final version that is the official plan?

One other question:  Soon we will have optional 'save' of plugin metadata in 
config.xml.  When CPR is turned off, there will be saved metadata which is no 
longer valid - i.e. a restore will fail.  This is because the 'name' used to 
fetch a plugin (cordova-plugin-device) as well as the location will change.   
Is there anything that can be done to mitigate that?  Is the name change really 
necessary - why can't we stick with the current names?

Thanks,
Leo 

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com] 
Sent: Wednesday, February 11, 2015 11:40 AM
To: dev@cordova.apache.org
Subject: Re: Schedule for npm transition

Correct! For the first 3 months, all requests will hit CPR first, if CPR
fails, we will try to fetch from npm.

If users run cordova plugin add cordova-plugin-device, it would hit CPR,
fail, go to npm, succeed.

If we use the mapper module, cordova plugin add
org.apache.cordova.device would be converted to cordova-plugin-device, hit
CPR, fail, go to npm, succeed.

After 3 months, cordova plugin add cordova-plugin-device would hit npm
first and succeed.

We want to use these 3 months to get our developers to update their tools
and use the new names for plugins to install.

On Wed, Feb 11, 2015 at 10:36 AM, Michal Mocny mmo...@chromium.org wrote:

 Steve, npm fetch default only affects plugins that use same name in both
 places, right?

 If we create cordova-plugin-device today, and tell users to start using
 cordova plugin add cordova-plugin-device, then we will get much user
 feedback on npm fetching far before May 18th, right?

 On Wed, Feb 11, 2015 at 1:09 PM, Steven Gill stevengil...@gmail.com
 wrote:

  We don't have one yet but we should pick dates soon.
 
  How about:
 
  CPR Switch to read only: Monday, May 18th
  NPM fetch becomes default: Monday, May 18th
  CPR offline: Monday, August 17th
 
  Based on the following proposal:
 
 
 https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing
 
   - Need to start educating plugin developers to publish to npm as well as
  CPR for next three months. (blog post)
   - Need to educate users to install plugins via new names (if
 package-name
  is different than id). Our core plugins are being renamed from
  org.apache.cordova.device to cordova-plugin-device
  - Inform devs who are working with registry directly to pull plugins from
  npm instead of CPR. After 3 months, CPR plugins will start to become out
 of
  date compared to npm versions.
 
  Our next plugins release (after the one currently ongoing) will be
  published to npm as well as cpr.
 
 
 
  On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan gorkem.er...@gmail.com
  wrote:
 
  
   Is there a determined calendar for the npm move of the plugins?
   I think the scheduling of the transition is crucial for those who are
   using the plugin registry directly.
   --
   Gorkem
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
  
 


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-lib pull request: CB-8420 'cordova plugin add' should retr...

2015-02-11 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-lib/pull/162


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [GitHub] cordova-lib pull request: CB-8420 'cordova plugin add' should retr...

2015-02-11 Thread Andrew Grieve

ah, I missed that lstatSync throws an exception for non-string args. I
suppose that's fine. Will merge!


On Wed, Feb 11, 2015 at 2:54 PM, omefire g...@git.apache.org wrote:

 Github user omefire commented on a diff in the pull request:

 https://github.com/apache/cordova-lib/pull/162#discussion_r24527527

 --- Diff: cordova-lib/src/cordova/plugin.js ---
 @@ -114,6 +116,22 @@ module.exports = function plugin(command,
 targets, opts) {
  target = target.substring(0,
 target.length - 1);
  }

 +var parts = target.split('@');
 +var id = parts[0];
 +var version = parts[1];
 +
 +// If no version is specified, retrieve the
 version from config.xml
 +if(!version  !cordova_util.isUrl(id) 
 !cordova_util.isDirectory(id)){
 +events.emit('verbose', 'no version
 specified, retrieving version from config.xml');
 +var ver = getVersionFromConfigFile(id,
 cfg);
 +
 +if( cordova_util.isUrl(ver) ||
 cordova_util.isDirectory(ver) ){
 --- End diff --

 @agrieve, isDirectory does handle the null/undefined cases. I just
 tested it. Am I missing something ?


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Schedule for npm transition

2015-02-11 Thread Michal Mocny

Leo, restore will still work. The only information stored in the saves
list is a set of plugin ids (and versions?). Restoring will go through the
steps Steve outlines above, and either download from CPR or be mapped
automatically to the npm equivalent. After the deprecation cutoff, plugins
that aren't in the mapper may fail to restore -- so we could improve the
rollout plan by starting to warn users adding plugins that still fetch from
CPR.

-Michal

On Wed, Feb 11, 2015 at 2:58 PM, Treggiari, Leo leo.treggi...@intel.com
wrote:

The proposal contains suggestions, alternatives and comments.

https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing

When will there be a final version that is the official plan?

One other question: Soon we will have optional 'save' of plugin metadata
in config.xml. When CPR is turned off, there will be saved metadata which
is no longer valid - i.e. a restore will fail. This is because the 'name'
used to fetch a plugin (cordova-plugin-device) as well as the location will
change. Is there anything that can be done to mitigate that? Is the name
change really necessary - why can't we stick with the current names?

Thanks,
Leo

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com]
Sent: Wednesday, February 11, 2015 11:40 AM
To: dev@cordova.apache.org
Subject: Re: Schedule for npm transition