Fil: yes I like the easy wins you describe.
Anis: agree on harder wins. The `emulate` cmd should require a
parameter and only launch platform emulators. The `run` cmd should
default to Ripple, and while we're in there we should kill the serve
command. Also agree, we should do a download to
this is nice man
On Mon, Mar 18, 2013 at 12:13 PM, James Jong wjamesj...@gmail.com wrote:
Nice work Fil!
-James Jong
On Mar 18, 2013, at 2:22 PM, Anis KADRI anis.ka...@gmail.com wrote:
Awesome!
On Mon, Mar 18, 2013 at 10:31 AM, Filip Maj f...@adobe.com wrote:
Alright committers and
Ok, picking this up again. At the working group Fil it would be good
to give our feedback on the manifest as it has related to the Cordova
reality.
I really dislike:
- scripts can only be loaded from inside the app package
- no inline scripts, no eval
I really like the idea of killing the
A couple of items I'd like to see get into 2.6:
1) Lorin's EXIF camera implementation
2) adding prompt dialog to the Notification API (completed, just needs to be
merged in)
https://github.com/apache/cordova-docs/pull/24
https://github.com/apache/cordova-js/pull/21
On the subject of no inline scripts or eval, this is used in the new v2
Chrome Apps too. It eliminates a wide spectrum of security risks at a
stroke, though it does require changing some of the older web dev practices
(onclick=whatever, primarily). If you're already attaching handlers using
Glad you've found this useful. If you have any ideas for improving the
docs, please feel free to make suggestions or file pull requests against
the cordova-docs repo.
One more thing I noticed is that you're using mCaptureCount and mFileName
from different threads. You might run into errors if
Read through FUTURE.md. Like it! Sounds amazing! Great work guys!
On Tue, Mar 19, 2013 at 5:02 PM, Filip Maj f...@adobe.com wrote:
For those unaware, cordova-plugman [1] is a tool under active development
that will be responsible for all the plugin things.
Braden, Anis and I are actively
+11 I really like the plan
On 13-03-20 10:23 AM, Andrew Grieve agri...@chromium.org wrote:
Read through FUTURE.md. Like it! Sounds amazing! Great work guys!
On Tue, Mar 19, 2013 at 5:02 PM, Filip Maj f...@adobe.com wrote:
For those unaware, cordova-plugman [1] is a tool under active
If there are no fixes going into these platforms, then there is no benefit
in their users updating them to newer versions of Cordova.
There's going to be more refactoring required when moving plugins to their
own repos. We'll really need owners for all platforms that will make the
transition, or
While we're discussing the platform level scripts, should we also attempt
to standardize the arguments that can be passed in as well?
On 13-03-20 6:19 AM, Brian LeRoux b...@brian.io wrote:
Fil: yes I like the easy wins you describe.
Anis: agree on harder wins. The `emulate` cmd should require a
cool stuff, guys, +1. Read through FUTURE.md, sounds great!
quick question: this is a general plugin manager, for third party plugins
as well as core plugins?
HA! Plugman, with 'man' for 'manager', I just now got that. And here I was
envisioning Anis dressed up as a superhero with a giant
I like the suggestions of having fewer commands. Actually, why not have
just one command? It would make for less copy/paste, and you'd only have to
use a single --help to see what you can do.
E.g.:
./cordova/cli.js build --profile=release
./cordova/cli.js build --profile=debug
./cordova/cli.js
Time's feeling right for a release.
I'm planning on going through pull requests today. Makes sense to get those
all in before starting the release.
On Wed, Mar 20, 2013 at 6:49 AM, James Jong wjamesj...@gmail.com wrote:
A couple of items I'd like to see get into 2.6:
1) Lorin's EXIF camera
That logo needs to happen.
plugman is the tool for downloading plugins, for inserting their config
file changes, installing their native code, and arranging for their JS
modules to be loaded at runtime.
cordova-cli is the tool for managing multiple platforms with one www
directory to rule them
I'm working on rolling some of the plugin JS loading logic into cordova-js.
If that makes this release then it will be possible to play with plugman
without also needing bleeding-edge JS. Note that this logic won't be active
if there are no plugins, so it shouldn't be a high-risk change to slide
Been outstanding for a month and it's the only change left before we can
say that all of the JS plugin code is isolated from Cordova's core JS code.
https://issues.apache.org/jira/browse/CB-2505
I just need someone that has a windows device to run the mobile spec with
it.
Deploy vs. Emulate: Deploy could be used to deploy to anything, emulator,
ripple, simulator, or actual device. I think perhaps deploy is the right
terminology in this regard than emulate?
I agree with Jeff that it would be valuable to standardize arguments as well,
in so far as those those
If there are no other takers, I could offer to do this. Should be able to get a
couple of devices to run the tests.
-Original Message-
From: Andrew Grieve [mailto:agri...@google.com]
Sent: Wednesday, March 20, 2013 8:52 AM
To: dev
Subject: Can someone sanity check this Windows Phone
That logo definitely needs to happen. But... what type of plug ;)
On Wed, Mar 20, 2013 at 8:45 AM, Braden Shepherdson bra...@chromium.orgwrote:
That logo needs to happen.
plugman is the tool for downloading plugins, for inserting their config
file changes, installing their native code, and
Awesome! That would be great! Thanks Parashuram
On Wed, Mar 20, 2013 at 12:21 PM, Parashuram Narasimhan (MS OPEN TECH)
panar...@microsoft.com wrote:
If there are no other takers, I could offer to do this. Should be able to
get a couple of devices to run the tests.
-Original
Great, thanks Braden!
So plugman operates more as a backend to the CLI? If I wanted a plugin
included, I'd throw it in the CLI plugins/ dir and the CLI through Plugman
woud take it from there?
I imagined an NA grounded I imagined a NA grounded
I'd like to see the exif stuff in this release too, glad we are holding
off. I'll publish my test spec later today for code review and sanity
check. It's a big chuck of complex code :)
On Wed, Mar 20, 2013 at 10:24 AM, Filip Maj f...@adobe.com wrote:
Alright sounds like we need to wait on
My changes are in.
On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj f...@adobe.com wrote:
Alright sounds like we need to wait on those pull reqs.
Braden, if you get it in time, great, otherwise, not a big deal.
Related: can someone recap the newer release/branching/tagging approach we
talked
Weird. Mobile-spec detects the newline at the end of this output now (the
line hasn't changed since last year):
https://github.com/don/cordova-filetransfer/blob/master/server.js#L30
Screenshot:
[image: Inline image 1]
On Wed, Mar 20, 2013 at 10:45 AM, Shazron shaz...@gmail.com wrote:
Weird. Mobile-spec detects the newline at the end of this output now (the
line hasn't changed since last year):
https://github.com/don/cordova-filetransfer/blob/master/server.js#L30
Maybe this has something to do with the newer version of node or formidable?
On Wed, Mar 20, 2013 at 1:45 PM, Shazron shaz...@gmail.com wrote:
Weird. Mobile-spec detects the newline at the end of this output now (the
line hasn't changed since last year):
Agreed, I am summarizing my thoughts on the other thread, but as Gord
originally insinuated, these commands should lie in cordova-cli, not in
the underlying platform scripts.
On 3/20/13 10:32 AM, Michael Brooks mich...@michaelbrooks.ca wrote:
We have a discussion going on the Cordova list
Benn, can you quickly run mobile-spec on a windows device with the below
code and let us know if/how well it passes?
On 3/20/13 10:04 AM, Andrew Grieve agri...@chromium.org wrote:
Awesome! That would be great! Thanks Parashuram
On Wed, Mar 20, 2013 at 12:21 PM, Parashuram Narasimhan (MS OPEN
Plugman operates on its own. The CLI consumes it as the tool to handle
plugins.
Plugman has a full, detailed API of its own. Check out the read me. It
handles install and uninstall of plugins based on the plugins.xml spec
(which is also in the plugman read me).
Cordova-cli offers a basic
Please see CB-2600 for details, but I want to bring this issue back to the
list: the cordova.js loader in mobile-spec inspecting userAgent to
determine what extra cordova.js to load.
Why I'm against it:
1. It's sole purpose is to pander to laziness. The SINGLE use case it
exists for is making a
The correct solution, to me, is mobile-spec as a plugin. Why does it even
have a cordova.js in it?
I've turned our chrome-spec test suite for the Chrome Apps stuff into a
plugin that just has an asset src=www / in it to copy its whole
contents into the platform www folders when you install it. It
I consider this change a stop-gap until we have a CLI-based mobile-spec app
to work with.
Before the change, the project is broken by default and requires you to
copy in a script for it to work.
After the change, it's still broken by default, but now allows you to have
a script-per-platform, so
Yes, the use case is laziness but not for the reasons you outline:
mobile-spec project doesn't have cordova.js set as an ignored file in git
(and in fact, cordova.js does some stuff in there), so if you make changes
to mobile-spec itself, you have to take care not to add changes to
cordova.js as
Speaking of logos, I was planning on making another 8 bit sticker for the
next PhoneGap day. The PlugMan character is still in the works :D
[image: Inline images 1]
+1 for the future md as well. It looks great.
I'm also working on a branch of cordova cli trying to get it integrating
with plugman
I think we should do the least amount of work given that this will change
like Braden outlined. Andrew is right, this was a temporary hack to make
testing simpler (for me, and those around me). But I should totally have
filed feature requests to add support for the other platforms to the regex!
Thanks everyone for chiming in, really appreciate this.
I'm of the same opinion as Michael. The current confusion started because
of (arguably) ambiguous terminology used for script names and no explicit
behavior for each listed out. My goal is to arrive at a consensus on the
naming and behavior
This recent security talk talks about why inline scripts are on the way
out:
https://www.youtube.com/watch?feature=player_embeddedv=WljJ5guzcLs
Thanks for this, listening to it now :)
A good amount of the spec deals with application distribution, which is
out
of our hands when talking about App
Actually dude talks about CSP 1.1 supporting whitelisting of inline
scripts ?
On 3/20/13 8:39 AM, Andrew Grieve agri...@chromium.org wrote:
This recent security talk talks about why inline scripts are on the way
out:
https://www.youtube.com/watch?feature=player_embeddedv=WljJ5guzcLs
A good
Thanks for the summary Fil, I like where this is going. I know that sounds
like a lot
of scripts but we're building them for the cordova-cli to use, so i like
the idea of breaking
them out so each script does a *very specific* task with as little-to-no
(the cli can handle that):
clean, log,
On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes benn.ma...@gmail.com wrote:
I know that sounds
like a lot
of scripts but we're building them for the cordova-cli to use, so i like
the idea of breaking
them out so each script does a *very specific* task with as little-to-no
No we're not.
Ya ya ya we're all on agreement on this specific issue. The underlying
platform scripts can be used regardless of whether you're using
cordova-cli or not.
On 3/20/13 3:51 PM, Anis KADRI anis.ka...@gmail.com wrote:
On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes benn.ma...@gmail.com wrote:
I know
https://github.com/apache/cordova-labs/pull/2
On Wed, Mar 20, 2013 at 6:25 PM, Shazron shaz...@gmail.com wrote:
I created a cordova-filetransfer branch off cordova-labs. It's not
replicated on Github yet but it is on Apache. Once it is there, you can do
the pull request against the
+1 to Micheal's API.
I am going to do the initial integration in with the ripple command (just
to keep that commit isolated to some changes to serve and the new ripple
command).
On Wed, Mar 20, 2013 at 2:30 PM, Filip Maj f...@adobe.com wrote:
Agreed, I am summarizing my thoughts on the other
I really like Anis's suggestion of just four scripts. What's the motivation
for having many scripts? Having fewer will dramatically reduce copy paste
bugs. It will also aid discoverability (since you'll get --help instead of
just ls and infer from the name what they do).
On Wed, Mar 20, 2013 at
Sounds reasonable. I like small focused scripts but the argument of
duplicated code across different files is a good one.
On 3/20/13 7:36 PM, Andrew Grieve agri...@chromium.org wrote:
I really like Anis's suggestion of just four scripts. What's the
motivation
for having many scripts? Having
Those that people wanted in before the release are in. FYI - I'm not
working tomorrow (back friday). Feel free to start the release train though.
Noticed a cordova-js pull request for Windows and for Blackberry. Would be
good if someone could comment on them.
Thanks for doing the merges, Andrew!
-James Jong
On Mar 20, 2013, at 11:33 PM, Andrew Grieve agri...@google.com wrote:
Those that people wanted in before the release are in. FYI - I'm not
working tomorrow (back friday). Feel free to start the release train though.
Noticed a cordova-js pull
47 matches
Mail list logo
