CLI downloads

[Anis KADRI]

http://npm-stat.vorb.de/charts.html?package=cordova

Re: Why CLI & Plugman are so slow

[Michal Mocny]

Not nested as in, for any single command we don't launch many subprocesses,
maybe just a single invocation.  So, the bulk of the time is spent outside
of the overhead of this single slow utility.  I think!


On Fri, Aug 2, 2013 at 3:49 PM, Anis KADRI  wrote:

> not nested as in we're using it in synchronous way ?
>
> On Fri, Aug 2, 2013 at 12:30 PM, Michal Mocny  wrote:
> > Just did a few quick tests:  while shelljs exec may be slow, seems we are
> > not using it in a nested way (which seems quite obvious).
> >
> > I wrote a quick benchmark to:
> >
> > cordova plugin ls
> > cordova platform ls
> > cordova prepare
> >
> > in a loop a bunch of times and see almost zero time difference replacing
> > shelljs with shelljs-ffi.  I would imagine that means very little benefit
> > to replacing with child_process as well, at least for a perf standpoint.
> >  It may still be worth doing for other benefits, but in the interest of
> > trying to make cordova-cli faster, I'm going to benchmark for other
> > bottlenecks.
> >
> > -Michal
> >
> >
> > On Thu, Jul 25, 2013 at 1:57 PM, Filip Maj  wrote:
> >
> >> cheers
> >>
> >> On 7/25/13 10:54 AM, "Andrew Grieve"  wrote:
> >>
> >> >Issues created.
> >> >https://issues.apache.org/jira/browse/CB-4398
> >> >https://issues.apache.org/jira/browse/CB-4397
> >> >
> >> >
> >> >On Thu, Jul 25, 2013 at 1:41 PM, Filip Maj  wrote:
> >> >
> >> >> Chalk it up as another issue.
> >> >>
> >> >> Feel free to help out with CLI/plugman tagged issues everyone. Lots
> of
> >> >> work there! ;)
> >> >>
> >> >> On 7/25/13 10:39 AM, "Anis KADRI"  wrote:
> >> >>
> >> >> >xD. +1 for child_process because it comes with node too eh :)
> >> >> >
> >> >> >On Thu, Jul 25, 2013 at 10:36 AM, Filip Maj  wrote:
> >> >> >> Changed your named to Gmail now huh Jesse?
> >> >> >>
> >> >> >> On 7/25/13 10:32 AM, "Gmail"  wrote:
> >> >> >>
> >> >> >>>+1 to child_process or leave it slow.
> >> >> >>>
> >> >> >>>Sent from my iPhone
> >> >> >>>
> >> >> >>>On Jul 25, 2013, at 10:28 AM, Filip Maj  wrote:
> >> >> >>>
> >> >>  Yeah that¹s how a lot of the "hey this works native on windows"
> >> >> modules
> >> >> on
> >> >>  npm works: they have to compile it D:
> >> >> 
> >> >>  On 7/25/13 10:26 AM, "Andrew Grieve" 
> wrote:
> >> >> 
> >> >> > just tried it, and it "does", but only if you have both python
> and
> >> >> >visual
> >> >> > studio installed on your machine. Guess it builds the .dll at
> npm
> >> >> >install
> >> >> > time :(
> >> >> >
> >> >> >
> >> >> > On Thu, Jul 25, 2013 at 1:23 PM, Anis KADRI <
> anis.ka...@gmail.com
> >> >
> >> >> >wrote:
> >> >> >
> >> >> >> https://github.com/rbranson/node-ffi
> >> >> >>
> >> >> >> looks like it does
> >> >> >>
> >> >> >> On Thu, Jul 25, 2013 at 10:14 AM, Filip Maj 
> >> >>wrote:
> >> >> >>> Does it work with Windows?
> >> >> >>>
> >> >> >>> On 7/25/13 10:11 AM, "Andrew Grieve" 
> >> >>wrote:
> >> >> >>>
> >> >>  Looks like the fix is pretty easy:
> >> >> 
> >> >>  agrieve@agrieve-macbookpro ~/git/cordova/tmp$ time node
> go3.js
> >> >>  went 0 times
> >> >>  went 10 times
> >> >>  went 20 times
> >> >>  went 30 times
> >> >>  went 40 times
> >> >>  went 50 times
> >> >>  went 60 times
> >> >>  went 70 times
> >> >>  went 80 times
> >> >>  went 90 times
> >> >>  went 100 times
> >> >> 
> >> >>  real 0m0.444s
> >> >>  user 0m0.266s
> >> >>  sys 0m0.158s
> >> >> 
> >> >> 
> >> >>  All I did was replace "shelljs" with "shelljs-ffi".
> >> >> 
> >> >> 
> >> >>  On Thu, Jul 25, 2013 at 12:53 PM, Filip Maj 
> >> >> wrote:
> >> >> 
> >> >> > Cool, nice work.
> >> >> >
> >> >> > We could either try to contribute to shelljs or rip it out
> >> >>and go
> >> >> >> all
> >> >> > child process all the time
> >> >> >
> >> >> > In any case I think this bench should be submitted to
> shelljs
> >> >> >repo.
> >> >> > @r2r,
> >> >> > dude who maintains it, would probably like to know
> >> >> >
> >> >> > On 7/25/13 9:50 AM, "Andrew Grieve" 
> >> >> wrote:
> >> >> >
> >> >> >> One reason: shelljs.exec()
> >> >> >>
> >> >> >> Did a test to see how many times I could execute "true". 9
> >> >> >>seconds
> >> >> >> vs
> >> >> > .5
> >> >> >> seconds!
> >> >> >>
> >> >> >>
> >> >> >> agrieve@agrieve-macbookpro ~/git/cordova/tmp$ time node
> >> >> >> shelljstest.js
> >> >> >> went 0 times
> >> >> >> went 10 times
> >> >> >> went 20 times
> >> >> >> went 30 times
> >> >> >> went 40 times
> >> >> >> went 50 times
> >> >> >> went 60 times
> >> >> >> went 70 t

Re: What's left for plugman registry?

[Andrew Grieve]

Bugs created: https://issues.apache.org/jira/browse/CB-4489

More discussion needed for the CB-4490 I think.


On Wed, Jul 31, 2013 at 7:13 PM, Anis KADRI  wrote:

> as for number 1: https://wiki.apache.org/cordova/PluginDiscovery. It's
> brief and concise but it should get you going.
>
> On Wed, Jul 31, 2013 at 3:46 PM, Filip Maj  wrote:
> > I believe there is an issue filed already for #3, check JIRA under
> PLugman
> >
> > On 7/31/13 2:09 PM, "Anis KADRI"  wrote:
> >
> >>1. I need to update the wiki but it's fairly easy. We got a free
> >>Irisouch instance for cordova (I keep typing Irishcouch for whatever
> >>reason :-X).
> >>2. Downloads are not currently tracked.
> >>3. Version checks have not been implemented yet. It should not be too
> >>hard to implement though.
> >>4. Nothing is documented yet (other than the project's help and
> >>README.rds).
> >>
> >>Maybe create an issue for 2, 3 and 4. I will take care of 1 this week.
> >>
> >>On Wed, Jul 31, 2013 at 1:38 PM, Andrew Grieve 
> >>wrote:
> >>> Definitely our most exciting feature coming up, so I wanted to get the
> >>>ball
> >>> rolling on enumerating what's left before we can launch it.
> >>>
> >>> Here's some things I can think of, please add to it (or subtract if you
> >>> disagree), and then I'll make sure there are JIRA issues:
> >>>
> >>> 1. Instructions for setting up the couchdb server (are we just going to
> >>>use
> >>> iriscouch like npm does? Apache VM issue is stalled).
> >>> - Docs for how to set up your own (federated) server are not launch
> >>> blocking.
> >>> 2. Ensure download counts are being tracked (even if we can't report
> >>>them
> >>> yet)
> >>> 3. Finish implementing version checks  version == min-plugman
> >>> version,  version == min-cordova-PLATFORM version.
> >>> - Checks for sdk and os versions are not launch blocking I don't
> >>>think.
> >>> 4. cordova-docs for how to use the registry as a user & as a plugin
> >>> developer.
> >>>
> >>> Andrew
> >
>

Re: Serve vs. opening an HTML file in the browser

[Anis KADRI]

XHRs won't work by default on certain browsers such as Chrome. I don't
think there are any other benefits.
This restriction does not exist on a device.

On Fri, Aug 2, 2013 at 1:13 PM, John M. Wargo  wrote:
> Can someone help me understand why I would want to use cordova serve rather
> than just loading the web content in the browser directly (through File -
> Open for example)?
>
> Is there something special that serve does that makes this approach better?

Serve vs. opening an HTML file in the browser

[John M. Wargo]

Can someone help me understand why I would want to use cordova serve rather 
than just loading the web content in the browser directly (through File - Open 
for example)?

Is there something special that serve does that makes this approach better?

Re: [plugins] Proper handling of subsequant calls in Media plugin

[Jesse]

Even the w3 media spec does not appear to define this.[1]
+1 to doing what Anis's stereo system does.

[1]
http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#dom-media-play

@purplecabbage
risingj.com


On Fri, Aug 2, 2013 at 12:03 PM, Anis KADRI  wrote:

> Whatever the behavior, I also think it should be documented.
>
> The behavior should be in my opinion similar to what a stereo system
> would do if you pressed any of the buttons. That is
> - play(): if playing then ignore otherwise start playing if paused/stopped.
> - pause(): if paused/stopped then ignore otherwise pause.
> - stop(): if paused/stopped then ignore otherwise stop.
>
> On Fri, Aug 2, 2013 at 9:15 AM, James Jong  wrote:
> > For iOS, a play during play state would restart the audio at the
> beginning.  I agree we should have a consistent behavior that is documented.
> >
> > -James Jong
> >
> > On Aug 2, 2013, at 11:33 AM, Lorin Beer 
> wrote:
> >
> >> I ran into this sometime ago on the android media API. The relevant
> >> conversation is likely deeply buried, and we should consider documenting
> >> the appropriate behavior somewhere permanent.
> >>
> >> My opinion is that appropriate behavior is dependent on the function
> being
> >> called and the current state. A FSM could capture this.
> >> In terms of  during  state, I would recommend that the
> plugin
> >> executes the latest command normally, playing media from a new source or
> >> restarting the currently executing media as if the play command had been
> >> received in the  state.
> >>
> >> - Lorin
> >>
> >>
> >> On Thu, Aug 1, 2013 at 1:47 PM, Benn Mapes 
> wrote:
> >>
> >>> Working on https://issues.apache.org/jira/browse/CB-3783, it appears
> that
> >>> there is no documentation on how the media plugin should handle
> subsequent
> >>> calls of the same function.
> >>>
> >>> An example would be calling my_media.play() multiple times when the
> >>> my_media is already playing. Should this be swallowed by the plugin and
> >>> ignored? Should we respond with a
> >>> MediaError<
> >>>
> http://cordova.apache.org/docs/en/3.0.0/cordova_media_media.md.html#MediaError
>  .MEDIA_ERR_ABORTED
> >>> and a message saying the media is already playing? What about
> subsequent
> >>> calls to my_media.pause() when the media is already paused?
> >>>
> >>> Was just wondering what other platforms have implemented for this and
> what
> >>> the proper way of handling subsequent calls is.
> >>>
> >>> ~Benn
> >>>
> >
>

Re: Why CLI & Plugman are so slow

[Anis KADRI]

not nested as in we're using it in synchronous way ?

On Fri, Aug 2, 2013 at 12:30 PM, Michal Mocny  wrote:
> Just did a few quick tests:  while shelljs exec may be slow, seems we are
> not using it in a nested way (which seems quite obvious).
>
> I wrote a quick benchmark to:
>
> cordova plugin ls
> cordova platform ls
> cordova prepare
>
> in a loop a bunch of times and see almost zero time difference replacing
> shelljs with shelljs-ffi.  I would imagine that means very little benefit
> to replacing with child_process as well, at least for a perf standpoint.
>  It may still be worth doing for other benefits, but in the interest of
> trying to make cordova-cli faster, I'm going to benchmark for other
> bottlenecks.
>
> -Michal
>
>
> On Thu, Jul 25, 2013 at 1:57 PM, Filip Maj  wrote:
>
>> cheers
>>
>> On 7/25/13 10:54 AM, "Andrew Grieve"  wrote:
>>
>> >Issues created.
>> >https://issues.apache.org/jira/browse/CB-4398
>> >https://issues.apache.org/jira/browse/CB-4397
>> >
>> >
>> >On Thu, Jul 25, 2013 at 1:41 PM, Filip Maj  wrote:
>> >
>> >> Chalk it up as another issue.
>> >>
>> >> Feel free to help out with CLI/plugman tagged issues everyone. Lots of
>> >> work there! ;)
>> >>
>> >> On 7/25/13 10:39 AM, "Anis KADRI"  wrote:
>> >>
>> >> >xD. +1 for child_process because it comes with node too eh :)
>> >> >
>> >> >On Thu, Jul 25, 2013 at 10:36 AM, Filip Maj  wrote:
>> >> >> Changed your named to Gmail now huh Jesse?
>> >> >>
>> >> >> On 7/25/13 10:32 AM, "Gmail"  wrote:
>> >> >>
>> >> >>>+1 to child_process or leave it slow.
>> >> >>>
>> >> >>>Sent from my iPhone
>> >> >>>
>> >> >>>On Jul 25, 2013, at 10:28 AM, Filip Maj  wrote:
>> >> >>>
>> >>  Yeah that¹s how a lot of the "hey this works native on windows"
>> >> modules
>> >> on
>> >>  npm works: they have to compile it D:
>> >> 
>> >>  On 7/25/13 10:26 AM, "Andrew Grieve"  wrote:
>> >> 
>> >> > just tried it, and it "does", but only if you have both python and
>> >> >visual
>> >> > studio installed on your machine. Guess it builds the .dll at npm
>> >> >install
>> >> > time :(
>> >> >
>> >> >
>> >> > On Thu, Jul 25, 2013 at 1:23 PM, Anis KADRI > >
>> >> >wrote:
>> >> >
>> >> >> https://github.com/rbranson/node-ffi
>> >> >>
>> >> >> looks like it does
>> >> >>
>> >> >> On Thu, Jul 25, 2013 at 10:14 AM, Filip Maj 
>> >>wrote:
>> >> >>> Does it work with Windows?
>> >> >>>
>> >> >>> On 7/25/13 10:11 AM, "Andrew Grieve" 
>> >>wrote:
>> >> >>>
>> >>  Looks like the fix is pretty easy:
>> >> 
>> >>  agrieve@agrieve-macbookpro ~/git/cordova/tmp$ time node go3.js
>> >>  went 0 times
>> >>  went 10 times
>> >>  went 20 times
>> >>  went 30 times
>> >>  went 40 times
>> >>  went 50 times
>> >>  went 60 times
>> >>  went 70 times
>> >>  went 80 times
>> >>  went 90 times
>> >>  went 100 times
>> >> 
>> >>  real 0m0.444s
>> >>  user 0m0.266s
>> >>  sys 0m0.158s
>> >> 
>> >> 
>> >>  All I did was replace "shelljs" with "shelljs-ffi".
>> >> 
>> >> 
>> >>  On Thu, Jul 25, 2013 at 12:53 PM, Filip Maj 
>> >> wrote:
>> >> 
>> >> > Cool, nice work.
>> >> >
>> >> > We could either try to contribute to shelljs or rip it out
>> >>and go
>> >> >> all
>> >> > child process all the time
>> >> >
>> >> > In any case I think this bench should be submitted to shelljs
>> >> >repo.
>> >> > @r2r,
>> >> > dude who maintains it, would probably like to know
>> >> >
>> >> > On 7/25/13 9:50 AM, "Andrew Grieve" 
>> >> wrote:
>> >> >
>> >> >> One reason: shelljs.exec()
>> >> >>
>> >> >> Did a test to see how many times I could execute "true". 9
>> >> >>seconds
>> >> >> vs
>> >> > .5
>> >> >> seconds!
>> >> >>
>> >> >>
>> >> >> agrieve@agrieve-macbookpro ~/git/cordova/tmp$ time node
>> >> >> shelljstest.js
>> >> >> went 0 times
>> >> >> went 10 times
>> >> >> went 20 times
>> >> >> went 30 times
>> >> >> went 40 times
>> >> >> went 50 times
>> >> >> went 60 times
>> >> >> went 70 times
>> >> >> went 80 times
>> >> >> went 90 times
>> >> >> went 100 times
>> >> >>
>> >> >> real 0m8.873s
>> >> >> user 0m10.941s
>> >> >> sys 0m6.005s
>> >> >> agrieve@agrieve-macbookpro ~/git/cordova/tmp$ time node
>> >> >> child_processtest.js
>> >> >> went 10 times
>> >> >> went 20 times
>> >> >> went 30 times
>> >> >> went 40 times
>> >> >> went 50 times
>> >> >> went 60 times
>> >> >> went 70 times
>> >> >> went 80 times
>> >> >> 

Re: Why CLI & Plugman are so slow

[Michal Mocny]

Just did a few quick tests:  while shelljs exec may be slow, seems we are
not using it in a nested way (which seems quite obvious).

I wrote a quick benchmark to:

cordova plugin ls
cordova platform ls
cordova prepare

in a loop a bunch of times and see almost zero time difference replacing
shelljs with shelljs-ffi.  I would imagine that means very little benefit
to replacing with child_process as well, at least for a perf standpoint.
 It may still be worth doing for other benefits, but in the interest of
trying to make cordova-cli faster, I'm going to benchmark for other
bottlenecks.

-Michal


On Thu, Jul 25, 2013 at 1:57 PM, Filip Maj  wrote:

> cheers
>
> On 7/25/13 10:54 AM, "Andrew Grieve"  wrote:
>
> >Issues created.
> >https://issues.apache.org/jira/browse/CB-4398
> >https://issues.apache.org/jira/browse/CB-4397
> >
> >
> >On Thu, Jul 25, 2013 at 1:41 PM, Filip Maj  wrote:
> >
> >> Chalk it up as another issue.
> >>
> >> Feel free to help out with CLI/plugman tagged issues everyone. Lots of
> >> work there! ;)
> >>
> >> On 7/25/13 10:39 AM, "Anis KADRI"  wrote:
> >>
> >> >xD. +1 for child_process because it comes with node too eh :)
> >> >
> >> >On Thu, Jul 25, 2013 at 10:36 AM, Filip Maj  wrote:
> >> >> Changed your named to Gmail now huh Jesse?
> >> >>
> >> >> On 7/25/13 10:32 AM, "Gmail"  wrote:
> >> >>
> >> >>>+1 to child_process or leave it slow.
> >> >>>
> >> >>>Sent from my iPhone
> >> >>>
> >> >>>On Jul 25, 2013, at 10:28 AM, Filip Maj  wrote:
> >> >>>
> >>  Yeah that¹s how a lot of the "hey this works native on windows"
> >> modules
> >> on
> >>  npm works: they have to compile it D:
> >> 
> >>  On 7/25/13 10:26 AM, "Andrew Grieve"  wrote:
> >> 
> >> > just tried it, and it "does", but only if you have both python and
> >> >visual
> >> > studio installed on your machine. Guess it builds the .dll at npm
> >> >install
> >> > time :(
> >> >
> >> >
> >> > On Thu, Jul 25, 2013 at 1:23 PM, Anis KADRI  >
> >> >wrote:
> >> >
> >> >> https://github.com/rbranson/node-ffi
> >> >>
> >> >> looks like it does
> >> >>
> >> >> On Thu, Jul 25, 2013 at 10:14 AM, Filip Maj 
> >>wrote:
> >> >>> Does it work with Windows?
> >> >>>
> >> >>> On 7/25/13 10:11 AM, "Andrew Grieve" 
> >>wrote:
> >> >>>
> >>  Looks like the fix is pretty easy:
> >> 
> >>  agrieve@agrieve-macbookpro ~/git/cordova/tmp$ time node go3.js
> >>  went 0 times
> >>  went 10 times
> >>  went 20 times
> >>  went 30 times
> >>  went 40 times
> >>  went 50 times
> >>  went 60 times
> >>  went 70 times
> >>  went 80 times
> >>  went 90 times
> >>  went 100 times
> >> 
> >>  real 0m0.444s
> >>  user 0m0.266s
> >>  sys 0m0.158s
> >> 
> >> 
> >>  All I did was replace "shelljs" with "shelljs-ffi".
> >> 
> >> 
> >>  On Thu, Jul 25, 2013 at 12:53 PM, Filip Maj 
> >> wrote:
> >> 
> >> > Cool, nice work.
> >> >
> >> > We could either try to contribute to shelljs or rip it out
> >>and go
> >> >> all
> >> > child process all the time
> >> >
> >> > In any case I think this bench should be submitted to shelljs
> >> >repo.
> >> > @r2r,
> >> > dude who maintains it, would probably like to know
> >> >
> >> > On 7/25/13 9:50 AM, "Andrew Grieve" 
> >> wrote:
> >> >
> >> >> One reason: shelljs.exec()
> >> >>
> >> >> Did a test to see how many times I could execute "true". 9
> >> >>seconds
> >> >> vs
> >> > .5
> >> >> seconds!
> >> >>
> >> >>
> >> >> agrieve@agrieve-macbookpro ~/git/cordova/tmp$ time node
> >> >> shelljstest.js
> >> >> went 0 times
> >> >> went 10 times
> >> >> went 20 times
> >> >> went 30 times
> >> >> went 40 times
> >> >> went 50 times
> >> >> went 60 times
> >> >> went 70 times
> >> >> went 80 times
> >> >> went 90 times
> >> >> went 100 times
> >> >>
> >> >> real 0m8.873s
> >> >> user 0m10.941s
> >> >> sys 0m6.005s
> >> >> agrieve@agrieve-macbookpro ~/git/cordova/tmp$ time node
> >> >> child_processtest.js
> >> >> went 10 times
> >> >> went 20 times
> >> >> went 30 times
> >> >> went 40 times
> >> >> went 50 times
> >> >> went 60 times
> >> >> went 70 times
> >> >> went 80 times
> >> >> went 90 times
> >> >> went 100 times
> >> >>
> >> >> real 0m0.470s
> >> >> user 0m0.278s
> >> >> sys 0m0.228s
> >> >>
> >> >>
> >> >> Here's the code:
> >> >> shelljstest.js
> >> >>
> >> >> var

Re: [plugins] Proper handling of subsequant calls in Media plugin

[Anis KADRI]

Whatever the behavior, I also think it should be documented.

The behavior should be in my opinion similar to what a stereo system
would do if you pressed any of the buttons. That is
- play(): if playing then ignore otherwise start playing if paused/stopped.
- pause(): if paused/stopped then ignore otherwise pause.
- stop(): if paused/stopped then ignore otherwise stop.

On Fri, Aug 2, 2013 at 9:15 AM, James Jong  wrote:
> For iOS, a play during play state would restart the audio at the beginning.  
> I agree we should have a consistent behavior that is documented.
>
> -James Jong
>
> On Aug 2, 2013, at 11:33 AM, Lorin Beer  wrote:
>
>> I ran into this sometime ago on the android media API. The relevant
>> conversation is likely deeply buried, and we should consider documenting
>> the appropriate behavior somewhere permanent.
>>
>> My opinion is that appropriate behavior is dependent on the function being
>> called and the current state. A FSM could capture this.
>> In terms of  during  state, I would recommend that the plugin
>> executes the latest command normally, playing media from a new source or
>> restarting the currently executing media as if the play command had been
>> received in the  state.
>>
>> - Lorin
>>
>>
>> On Thu, Aug 1, 2013 at 1:47 PM, Benn Mapes  wrote:
>>
>>> Working on https://issues.apache.org/jira/browse/CB-3783, it appears that
>>> there is no documentation on how the media plugin should handle subsequent
>>> calls of the same function.
>>>
>>> An example would be calling my_media.play() multiple times when the
>>> my_media is already playing. Should this be swallowed by the plugin and
>>> ignored? Should we respond with a
>>> MediaError<
>>> http://cordova.apache.org/docs/en/3.0.0/cordova_media_media.md.html#MediaError
 .MEDIA_ERR_ABORTED
>>> and a message saying the media is already playing? What about subsequent
>>> calls to my_media.pause() when the media is already paused?
>>>
>>> Was just wondering what other platforms have implemented for this and what
>>> the proper way of handling subsequent calls is.
>>>
>>> ~Benn
>>>
>

Re: Command-line completion in Cordova CLI

[James Jong]

+1 for it being a separate install
-James Jong

On Jul 31, 2013, at 1:24 PM, Ian Clelland  wrote:

> On Wed, Jul 31, 2013 at 12:21 PM, Michael Sierra  wrote:
> 
>> For doc, pls clarify if tab completion is to be built into the product, or
>> if it involves a separate install.
> 
> 
> I think it would have to be a separate installation step, as it generally
> involves manipulating your .bashrc profile, and I don't think we'd want to
> do that as part of 'npm install' (But maybe we do :) )
> 
> 
>> I assume it works for clearly constrained sets of choices such as "plugin
>> rm" rather than "plugin add". Correct?
> 
> 
> For "plugin rm", it will complete based on the installed plugins. "plugin
> add" will autocomplete using directory entries, since that's the expected
> input.
> 
> I'll see if I can write some more complete docs about what it does and
> doesn't do.
> 
> Ian
> 
> 
>> Point me towards any appropriate info. Thanks
>> 
>> --Mike S
>> 
>> 
>> From: brian.ler...@gmail.com [brian.ler...@gmail.com] On Behalf Of Brian
>> LeRoux [b...@brian.io]
>> Sent: Wednesday, July 31, 2013 11:41 AM
>> To: dev@cordova.apache.org
>> Cc: Filip Maj
>> Subject: Re: Command-line completion in Cordova CLI
>> 
>> Yes I think this would be great. (Maybe add the docs to the cli guide tho?)
>> 
>> 
>> 
>> On Wed, Jul 31, 2013 at 8:26 AM, Ian Clelland 
>> wrote:
>>> I've been pretty happy with the state of my Bash command-line completion
>>> script for CLI -- I'd like to add it to the CLI repo, and include some
>> docs
>>> there about installing it on Unix-y systems.
>>> 
>>> Any objections? Better places for it? Horrible crash reports?
>>> 
>>> Ian
>> 

Re: [plugins] Proper handling of subsequant calls in Media plugin

[James Jong]

For iOS, a play during play state would restart the audio at the beginning.  I 
agree we should have a consistent behavior that is documented.

-James Jong

On Aug 2, 2013, at 11:33 AM, Lorin Beer  wrote:

> I ran into this sometime ago on the android media API. The relevant
> conversation is likely deeply buried, and we should consider documenting
> the appropriate behavior somewhere permanent.
> 
> My opinion is that appropriate behavior is dependent on the function being
> called and the current state. A FSM could capture this.
> In terms of  during  state, I would recommend that the plugin
> executes the latest command normally, playing media from a new source or
> restarting the currently executing media as if the play command had been
> received in the  state.
> 
> - Lorin
> 
> 
> On Thu, Aug 1, 2013 at 1:47 PM, Benn Mapes  wrote:
> 
>> Working on https://issues.apache.org/jira/browse/CB-3783, it appears that
>> there is no documentation on how the media plugin should handle subsequent
>> calls of the same function.
>> 
>> An example would be calling my_media.play() multiple times when the
>> my_media is already playing. Should this be swallowed by the plugin and
>> ignored? Should we respond with a
>> MediaError<
>> http://cordova.apache.org/docs/en/3.0.0/cordova_media_media.md.html#MediaError
>>> .MEDIA_ERR_ABORTED
>> and a message saying the media is already playing? What about subsequent
>> calls to my_media.pause() when the media is already paused?
>> 
>> Was just wondering what other platforms have implemented for this and what
>> the proper way of handling subsequent calls is.
>> 
>> ~Benn
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [plugins] Proper handling of subsequant calls in Media plugin

[Lorin Beer]

I ran into this sometime ago on the android media API. The relevant
conversation is likely deeply buried, and we should consider documenting
the appropriate behavior somewhere permanent.

My opinion is that appropriate behavior is dependent on the function being
called and the current state. A FSM could capture this.
In terms of  during  state, I would recommend that the plugin
executes the latest command normally, playing media from a new source or
restarting the currently executing media as if the play command had been
received in the  state.

- Lorin


On Thu, Aug 1, 2013 at 1:47 PM, Benn Mapes  wrote:

> Working on https://issues.apache.org/jira/browse/CB-3783, it appears that
> there is no documentation on how the media plugin should handle subsequent
> calls of the same function.
>
> An example would be calling my_media.play() multiple times when the
> my_media is already playing. Should this be swallowed by the plugin and
> ignored? Should we respond with a
> MediaError<
> http://cordova.apache.org/docs/en/3.0.0/cordova_media_media.md.html#MediaError
> >.MEDIA_ERR_ABORTED
> and a message saying the media is already playing? What about subsequent
> calls to my_media.pause() when the media is already paused?
>
> Was just wondering what other platforms have implemented for this and what
> the proper way of handling subsequent calls is.
>
> ~Benn
>

Re: Cordova 3.0.0 : link for get started

[vcf35]

Le 01/08/2013 22:17, Andrew Grieve a écrit :

Thanks for pointing that out. Looks like the readme is out of date (I'll
fix that up). Try here:
http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview


On Thu, Aug 1, 2013 at 11:27 AM, vcf35  wrote:


Hello,

I am just started with cordova under ubuntu 12.04x64.
After download cordova-3.0.0-src file, I can read in README.md :

  Get started

---
[Docs](http://docs.cordova.io/**guide_getting-started_index.**md.html
)



But the link is down.

Regards from France,
Olivier.




Nice,

Thank you very much.

Olivier.