HI GUYS!
I'm reviving this thread :)
There are a couple of issues filed for both CLI commands `ripple` and
`serve`. We've spoke in the past about axing `serve` in favor of `ripple`
(see below in this thread).
My suggestion: remove `serve` altogether in 3.0. There was consensus for
this before
+1
Currently the ripple command runs on top of serve [1] but should be really
easy to refactor.
Once the integration is a bit more solid we need to start routing emulate
commands for unsupported platforms to ripple.
[1] -
If the current 'serve' implementation needs axing, thats fine. However,
curious if you are implying that 'ripple' will be the only way to do repid
edit-refresh without rebuilding native components? We need a way to get
app updates to a device running e.g. app-harness right? I thought that was
My view is that both `ripple` and `serve` do essentially the same thing:
host local assets for viewing/editing/testing in a browser. Essentially
enabling that fast edit/refresh cycle without have to compile/redeploy to
a device every time. And as Gord chimed in, current `cordova ripple`
relies to
+1
I hacked serve together in a couple of hours, and it is not in active use.
Corporate network environments are generally not open to your phone
connecting directly to a serve running on your laptop or desktop, making
'serve' not very useful.
Braden
On Mon, Jun 10, 2013 at 2:25 PM, Filip Maj
Also with Ripple:
If you don't pass the ?enableRipple=true qs param it does exactly what
serve does ;)
On Mon, Jun 10, 2013 at 4:29 PM, Filip Maj f...@adobe.com wrote:
My view is that both `ripple` and `serve` do essentially the same thing:
host local assets for viewing/editing/testing in a
- App-harness is 99% just plain serving of files with these constraints:
- The folder to server is the *platform specific* www output artifact
(ie, after www/ and merges/ and plugins mush together)
- The final config.xml file is in a special location outside that folder,
and is handled specially
There is an interesting nugget here. Maybe there should be things like
./platforms/ripple (and ./platforms/chrome-packaged-app
???
makes sense to me.
On Mon, Jun 10, 2013 at 1:42 PM, Michal Mocny mmo...@chromium.org wrote:
- App-harness is 99% just plain serving of files with these
I suspect there will always be some minimal differences in
ripple/chrome-packaged-apps etc, but not sure how to best account for that.
Platform targets is an interesting idea; could we extend other platforms
without forking them? chrome-packaged-apps for ios/android is just a
workflow set of
https://uwaterloo.ca/engineering/events/first-robotics-waterloo-regional
I was a score keeper last year (two years ago?) and it was super cool.
On Fri, Mar 22, 2013 at 10:03 PM, Michal Mocny mmo...@chromium.org wrote:
Dan, my brother showed me this (he is mechatronics student at UW). Is it
I think this bleeds back into other discussions. It was mentioned in
the call earlier. I think some tacit agreement that ./serve goes away
and Ripple is the default ./emulate command. But lets discuss. (Just
this. Lets keep thread focused.)
+1
With this I would want to add the ability to add a platform to a project even
if we don't have the build dependencies.
Emulate would just default to ripple so is still usable if we can't build/deploy
Sent from my iPhone
On 2013-03-22, at 1:55 PM, Brian LeRoux b...@brian.io wrote:
I
omg I just realized this would fulfill offline use case vs lazy load vendoring
caching could be a future thing
might be a really nice path
On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner gtan...@gmail.com wrote:
+1
With this I would want to add the ability to add a platform to a project even
Very interesting. Combined with Bradens proposal to support pointing to a
local platform, looks very good.
Also note, offline isn't the only reason, platform support on a given
machine as well: ie, can test iPhone (sorta) on a linux box through
Ripple.
On Fri, Mar 22, 2013 at 2:15 PM, Brian
Yeah Michal,
That is the exact use case I had in mind. When we were a startup we
couldn't afford mac's so just used linux and ripple for all our contract
work and borrowed a friends macbook when we needed to compile.
On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny mmo...@chromium.org wrote:
Thats awesome ;)
On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner gtan...@gmail.com wrote:
Yeah Michal,
That is the exact use case I had in mind. When we were a startup we
couldn't afford mac's so just used linux and ripple for all our contract
work and borrowed a friends macbook when we
Like that plan. Say we proceed and land it in 2.6 to feel out.
On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj f...@adobe.com wrote:
I'm fine with removing server. In my mind ripple is just a serve command
on steroids. At this morning's meeting I believe some of the Googlers
expressed concerns
K lets try to land it in 2.6.0rc1. There is still time Gord! Blackberry +
iOS not tagged yet so we can land some more commits in cordova-cli
On 3/22/13 3:02 PM, Brian LeRoux b...@brian.io wrote:
Like that plan. Say we proceed and land it in 2.6 to feel out.
On Fri, Mar 22, 2013 at 2:50 PM,
+1
Sorry I'm late to the game, I was judging frisbee throwing, pyramid
climbing robots all day :-)
https://twitter.com/confusement/status/315162754619162625
On Fri, Mar 22, 2013 at 6:35 PM, Filip Maj f...@adobe.com wrote:
K lets try to land it in 2.6.0rc1. There is still time Gord!
To clarify - I don't mind if serve gets axed for now.
On Fri, Mar 22, 2013 at 6:02 PM, Brian LeRoux b...@brian.io wrote:
Like that plan. Say we proceed and land it in 2.6 to feel out.
On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj f...@adobe.com wrote:
I'm fine with removing server. In my mind
Merged into next [1].
I am currently at the pub and a beer or two in so I am not going to code to
much. If someone wants to axe serve (or refactor it to just use ripple)
that would be awesome.
[1] -
https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/heads/next
On
21 matches
Mail list logo
