You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Michal Mocny <mm...@google.com> on 2014/11/05 17:04:04 UTC
Summarizing thoughts on cordova-browser vs Ripple
We debated a bit about browser vs ripple at phonegap day (especially Intel
folks who have done lots of work here), and the my personal tldr; is that
there is in fact a home for both.
Basically, browser-platform is for getting apps running in a browser (duh)
with as much working functionality as possible. Its supposed to simplify
the 'if cordova then dialog else alert' problem, so you can build even more
of your app with just local development. Seemingly this could be used to
make targeting both web and app even easier.
Ripple is for instrumenting/debugging apps by manipulating plugins. Its
about having a UI that reaches into geolocation or camera and controls what
the plugin returns to the app. Its about re-running the same device events
over and over for tracking application logic changes.
Some of the work ripple has done traditionally can now in fact just be done
via browser DevTools, but their are still some cases where custom hooks
into plugins are the best way to provide a good local "simulator". (Chrome
DevTools at least now provide mobile emulation, unsure about others).
In my view, ripple should be built on top of the browser platform work, and
ideally also decouple the UI from the plugin instrumentation, but thats up
to the folks running that effort.
With all this in mind, I think the cordova-browser effort should proceed
with current direction, but keep in mind that more advanced plugin
instrumentation doesn't belong there.
-Michal
Idea for simulating plugins for Cordova Browser [was: RE:
Summarizing thoughts on cordova-browser vs Ripple]
Posted by Ali Satter <al...@outlook.com>.
+1 to what Kirupa said
The idea here would be to have a secondary workflow for the browser platform that would include the necessary metadata for mock plugin functionality. Ideally:
the mock behavior is implemented/provided by the pluginplugins provide optional model-based UI for controlling/simulating the mock plugin functionalitySomething like http://www.w3.org/2011/mbui/browser dev tools/IDE tools/browser extensions implement the model-based UI for plugin simulation
I am still at early stages of my design thoughts. Love to hear what others are thinking about.
-
ali
> From: panarasi@microsoft.com
> To: dev@cordova.apache.org
> Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
> Date: Wed, 5 Nov 2014 19:24:44 +0000
>
> �MSOpenTech is currently working on porting our ripple-platform prototype - https://github.com/MSOpenTech/cordova-ripple to work on top of cordova-browser. The question on how each plugin exposes a UI to provide mock data is still up for discussion, but Intel has a lot of context on that area.
>
> -----Original Message-----
> From: Kirupa Chinnathambi [mailto:kirupac@microsoft.com]
> Sent: Wednesday, November 5, 2014 11:04 AM
> To: dev@cordova.apache.org
> Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
>
> +1 to what you’ve both stated.
>
> Cordova-browser shouldn't be responsible for providing mock data, UI, or any additional functionality for simulating a plug-in. It’s primary goal is to (as you both mention) be responsible for getting apps to run in the browser. Simulating plug-in behavior would be external to that in some form or fashion.
>
> Cheers,
> Kirupa
>
> -----Original Message-----
> From: mikeywbrooks@gmail.com [mailto:mikeywbrooks@gmail.com] On Behalf Of Michael Brooks
> Sent: Wednesday, November 5, 2014 9:22 AM
> To: dev@cordova.apache.org
> Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
>
> >
> > In my view, ripple should be built on top of the browser platform
> > work, and ideally also decouple the UI from the plugin
> > instrumentation, but thats up to the folks running that effort.
>
>
>
>
> > With all this in mind, I think the cordova-browser effort should
> > proceed with current direction, but keep in mind that more advanced
> > plugin instrumentation doesn't belong there.
>
>
> This echo's my views on the Browser Platform and Ripple as well.
>
> Ideally, the Browser Platform is a production deployment environment for the web, while Ripple is debugging instrumentation that runs on the Browser Platform.
>
> On Wed, Nov 5, 2014 at 8:04 AM, Michal Mocny <mm...@google.com> wrote:
>
> > We debated a bit about browser vs ripple at phonegap day (especially
> > Intel folks who have done lots of work here), and the my personal
> > tldr; is that there is in fact a home for both.
> >
> > Basically, browser-platform is for getting apps running in a browser
> > (duh) with as much working functionality as possible. Its supposed to
> > simplify the 'if cordova then dialog else alert' problem, so you can
> > build even more of your app with just local development. Seemingly
> > this could be used to make targeting both web and app even easier.
> >
> > Ripple is for instrumenting/debugging apps by manipulating plugins.
> > Its about having a UI that reaches into geolocation or camera and
> > controls what the plugin returns to the app. Its about re-running the
> > same device events over and over for tracking application logic changes.
> >
> > Some of the work ripple has done traditionally can now in fact just be
> > done via browser DevTools, but their are still some cases where custom
> > hooks into plugins are the best way to provide a good local
> > "simulator". (Chrome DevTools at least now provide mobile emulation, unsure about others).
> >
> > In my view, ripple should be built on top of the browser platform
> > work, and ideally also decouple the UI from the plugin
> > instrumentation, but thats up to the folks running that effort.
> >
> > With all this in mind, I think the cordova-browser effort should
> > proceed with current direction, but keep in mind that more advanced
> > plugin instrumentation doesn't belong there.
> >
> > -Michal
> >
> �Т���������������������������������������������������������������������ХF�V�7V'67&�&R�R���âFWb�V�7V'67&�&T6�&F�f�6�R��&pФf�"FF�F����6����G2�R���âFWbֆV�6�&F�f�6�R��&p
RE: Summarizing thoughts on cordova-browser vs Ripple
Posted by "Lunev, Serge" <se...@intel.com>.
Thanks, Julian. Great summary!
Best,
Serge
@lunarserge
-----Original Message-----
From: Horn, Julian C [mailto:julian.c.horn@intel.com]
Sent: Tuesday, November 18, 2014 1:58 PM
To: dev@cordova.apache.org
Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
I'd like to answer some of the concerns that have flown by in this thread. Let me work from most recent to older.
First, in reply to Jesse's question, yes, this is how Ripple works today: it can run code prepared for any platform. That is, when you start to emulate a Cordova 3 project, Ripple calculates the platform associated with the currently selected device. So if the current device is an iPhone 5, the platform is "ios". Ripple then shells out to run a "cordova prepare ios". When that finishes, Ripple starts executing the output, which would be in platform/ios/www. This means you are executing the ios-specific sources for your app under ios emulation. If you have any merges, they would be resolved according to the ios rules.
The point of the cordova-browser and ripple-as-a-platform idea is to stop doing this, and rather have Ripple shell out to do "cordova prepare browser" (or "cordova prepare ripple") no matter what device is selected. This means you are executing not os-specific sources, but rather generic sources that are intended on a browser (or in a browser in ripple). The distinction between these two cases is what started this mail thread.
I think Serge what is saying that he likes the possibility of being able to package the emulation support for a plugin API in with the plugin itself, rather than having all the emulation support be in the emulator, as has been the case in the past. This provides a nice extensibility point that plugin authors could use as they see fit.
As for Brian's question about UI support in plugins, it's certainly true that anyone who wants to design a UI model for emulation of some new API will have to work within some extensible GUI context. This is really what Ripple gives you. The browser does not, and it seems unlikely that the developer tools in multiple browsers could agree on some kind of common extensibility framework.
For example, the Ripple UI provides the concept of a "panel". This is a separable module that is defined by its own HTML and CSS, along with whatever images or third party components are needed to make it all work. It's easy to add a panel to Ripple, and with that you get for free a framework where that panel can be opened, closed, hidden, and arranged within an accordion with other panels and so on. I made a prototype version of Ripple that demonstrates that it is possible to embed a panel definition into a plugin and have Ripple discover that panel and dynamically add it to the rest of the Ripple UI, as if it were part of Ripple to begin with. So this is certainly doable. It's the same amount of work to author and maintain the emulation code, no matter how it is packaged.
As to whether Ripple is "dead" or not, I would like to point out that Intel has a Ripple-derived product (we call it the Device Emulator) that is alive and well. It does not run as a stand-alone tool, but rather is integrated into the Intel XDK IDE. It is under active development and support. It has diverged somewhat from Ripple, mainly in the way it is integrated into the XDK and the way it supports Cordova 3. For example, we have an "auto-refresh" option that causes the emulator to restart when you modify a source file. We also have a button that launches a variant of the developer tools that appears to debug only the program under test, even though this is just one frame in a larger document.
Julian
-----Original Message-----
From: Jesse [mailto:purplecabbage@gmail.com]
Sent: Tuesday, November 18, 2014 4:04 PM
To: dev@cordova.apache.org
Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
Shouldn't ripple be able to emulate/monkey-patch any of the platforms?
If I am looking at and testing my cordova-ios app in ripple, I think I would want the cordova-ios.js to be run, and not cordova-browser.js, otherwise there could be latent issues that I would never see until I actually ran it on the device, or emulator. Hopefully the differences between each platform's cordova.js is insignificant, but I don't think that we know this for sure.
The code to inject/intercept ANY platform's cordova.exec is simple, really, it is <10 lines.
In my mind, ripple should be responsible for hooking it's own way in, and proxying, without extra specific built in support either by cordova-browser, or cordova-js.
@purplecabbage
risingj.com
On Tue, Nov 18, 2014 at 11:49 AM, Michal Mocny <mm...@chromium.org> wrote:
> Serge,
>
> That sounds like you disagree with Julian's earlier summary that
> Ripple should just intersect at the exec proxy level, and propose
> instead that Ripple should intersect by having "hooks" inside the
> cordova-browser plugin js-modules, correct?
>
> I think thats not impossible (plugin authors can do what they want),
> but perhaps should just happen on a case-by-case basis, as required.
> If you have ideas about an architecture that we should advise
> developers to use by default, I'm curious what that would even look like.
>
> -Michal
>
> On Tue, Nov 18, 2014 at 1:01 PM, Lunev, Serge <se...@intel.com>
> wrote:
>
> > Let me add two pennies from my side also then :)
> >
> > From the community perspective, I have little hope that a random
> > plugin author will care about anything beyond browser target for
> > his/her plugin for testing/debug purposes. I do think though that
> > putting a right architecture in place for something better than a
> > regular browser target can provide is important. 'Something better'
> > means here a way to hook up browser developer tools (or Ripple /
> > node-webkit combo in Intel XDK case) to control plugin behavior so
> > that input data could be controlled by appropriate UI in browser/XDK.
> >
> > For us in XDK the alternative would be to fully separate a plugin
> > from
> its
> > emulation. I.e. if we choose to support certain plugin emulation in
> > the XDK, that will be totally technically separate from its Cordova
> > implementation. While this is a viable alternative, this just
> > doesn't
> smell
> > right.
> >
> > Best,
> > Serge Lunev
> > Intel XDK Engineering Manager
> > @lunarserge
> >
> > -----Original Message-----
> > From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On
> > Behalf
> Of
> > Brian LeRoux
> > Sent: Tuesday, November 18, 2014 9:26 AM
> > To: dev@cordova.apache.org
> > Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
> >
> > I'm less interested in copying work being done faster/better in the
> > browser devtools. Certainly some UI abstractions are helpful (map
> controls,
> > acceleromter scrubbing widget, etc) but the returns for dev time are
> > diminishing for the effort to author/maintain. Esp bad considering
> > we'd have to pick UI paradigms and enforce them somehow.
> >
> > For my two pennies, providing an abstraction that allows authoring
> > time convenience of using browser with an eventual goal for open web
> publishing
> > would be the best architecture (and strategy) for Cordova to pursue.
> >
> > On Tue, Nov 18, 2014 at 9:12 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> > > On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden <ra...@adobe.com>
> wrote:
> > >
> > > >
> > > > >>
> > > > >> On 11/15/14, 2:17 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> > > > >>
> > > >
> > > > >>Not at all. What is it you think we are proposing? I'm
> > > > >>merely suggesting
> > > > >that the cordova-browser camera plugin implementation shouldn't
> > > > >*also* come with a DOM component that sits over top of your
> > > > >application to
> > > manipulate
> > > > >the camera. The existing BAAP camera implementation is great
> > > > >as
> > > currently
> > > > >implemented, and wouldn't change.
> > > > >
> > > > >Another example would better illustrate the difference: BAAP
> > > > >geolocation shim I believe should just use the browser
> > > > >geolocation api, or return a single fixed location if that
> > > > >isn't available. It needn't support programmatically / UI for
> > > > >manipulating custom location, which Ripple geolocation does.
> > > >
> > > > I’m with you on that - but I think that is an example that works
> > > > well w/o UI and other plugins may not. Let’s consider contacts,
> > > > specifically pickContact. I *would* be ok with a UI of some
> > > > sort, perhaps just 3
> > > simple
> > > > contacts in a list, that that user can select. In theory it
> > > > could also just automatically fire contactSuccess, but my point
> > > > is that I’m not opposed to it providing a bit of UI as well.
> > > >
> > > >
> > > > >>As an example, I¹ve got an app now which uses barcode scanning
> > > > >>for one small part. By adding the Browser platform to the
> > > > >>plugin, I am able to do all of my work in the browser now and
> > > > >>fake a barcode when I need it.
> > > > >>That
> > > > >> is a problem that - imo - is much more valuable than
> > > > >>supporting
> > > browser
> > > > >>as
> > > > >> a destination of my app.
> > > > >>
> > > > >
> > > > >If you just want to return a single fixed barcode, I agree BAAP
> > > > >should
> > > do
> > > > >this. If you want to be able to customize the barcode at
> > > > >runtime, with
> > > a
> > > > >simple UI that is automatically injected into your page as part
> > > > >of the runtime, then I think that is a task for Ripple (or
> > > > >other
> > emulators).
> > > >
> > > >
> > > > So I think this is the crux of our disagreement then. :) Right
> > > > now the plugin (and I wrote this, so I may be biased ;) uses a
> > > > prompt so you can enter a code. My thinking there was if you
> > > > didn’t care, you would type 1 and hit enter, but if you were
> > > > passing the bar code to some service, you could paste something
> > > > in. To me, that’s more useful then just using a
> > > hard
> > > > coded value you can’t tweak. I think that usefulness outweighs
> > > > the potential ‘loss’ of being able to run this as a real web app.
> > > >
> > >
> > > Fair enough. Sounds like you want some of what I've proposed
> > > Ripple could offer, but are concerned that Ripple won't be a
> > > viable/sustainable choice for you. To be honest, I share that concern.
> > >
> > > For the barcode scanning example, I think a popup with an input
> > > box is fine, even for prod, so long as the popup is presented as
> > > if to a user and not as if to a developer. Hopefully we can
> > > improve it to also offer an input type=image, or to use the webcam
> > > (I haven't looked, not sure if it does this yet).
> > >
> > > If we really want separate dev mode and prod mode for a given
> > > plugin, perhaps we can just add an api for toggle this. I just
> > > hope to set the precedent that the default isn't *just* for developer debugging.
> > >
> > > -Michal
> > >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [ X ܚX KK[XZ[
] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
] Z[ ܙݘK \X K ܙ B
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
RE: Summarizing thoughts on cordova-browser vs Ripple
Posted by "Horn, Julian C" <ju...@intel.com>.
I'd like to answer some of the concerns that have flown by in this thread. Let me work from most recent to older.
First, in reply to Jesse's question, yes, this is how Ripple works today: it can run code prepared for any platform. That is, when you start to emulate a Cordova 3 project, Ripple calculates the platform associated with the currently selected device. So if the current device is an iPhone 5, the platform is "ios". Ripple then shells out to run a "cordova prepare ios". When that finishes, Ripple starts executing the output, which would be in platform/ios/www. This means you are executing the ios-specific sources for your app under ios emulation. If you have any merges, they would be resolved according to the ios rules.
The point of the cordova-browser and ripple-as-a-platform idea is to stop doing this, and rather have Ripple shell out to do "cordova prepare browser" (or "cordova prepare ripple") no matter what device is selected. This means you are executing not os-specific sources, but rather generic sources that are intended on a browser (or in a browser in ripple). The distinction between these two cases is what started this mail thread.
I think Serge what is saying that he likes the possibility of being able to package the emulation support for a plugin API in with the plugin itself, rather than having all the emulation support be in the emulator, as has been the case in the past. This provides a nice extensibility point that plugin authors could use as they see fit.
As for Brian's question about UI support in plugins, it's certainly true that anyone who wants to design a UI model for emulation of some new API will have to work within some extensible GUI context. This is really what Ripple gives you. The browser does not, and it seems unlikely that the developer tools in multiple browsers could agree on some kind of common extensibility framework.
For example, the Ripple UI provides the concept of a "panel". This is a separable module that is defined by its own HTML and CSS, along with whatever images or third party components are needed to make it all work. It's easy to add a panel to Ripple, and with that you get for free a framework where that panel can be opened, closed, hidden, and arranged within an accordion with other panels and so on. I made a prototype version of Ripple that demonstrates that it is possible to embed a panel definition into a plugin and have Ripple discover that panel and dynamically add it to the rest of the Ripple UI, as if it were part of Ripple to begin with. So this is certainly doable. It's the same amount of work to author and maintain the emulation code, no matter how it is packaged.
As to whether Ripple is "dead" or not, I would like to point out that Intel has a Ripple-derived product (we call it the Device Emulator) that is alive and well. It does not run as a stand-alone tool, but rather is integrated into the Intel XDK IDE. It is under active development and support. It has diverged somewhat from Ripple, mainly in the way it is integrated into the XDK and the way it supports Cordova 3. For example, we have an "auto-refresh" option that causes the emulator to restart when you modify a source file. We also have a button that launches a variant of the developer tools that appears to debug only the program under test, even though this is just one frame in a larger document.
Julian
-----Original Message-----
From: Jesse [mailto:purplecabbage@gmail.com]
Sent: Tuesday, November 18, 2014 4:04 PM
To: dev@cordova.apache.org
Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
Shouldn't ripple be able to emulate/monkey-patch any of the platforms?
If I am looking at and testing my cordova-ios app in ripple, I think I would want the cordova-ios.js to be run, and not cordova-browser.js, otherwise there could be latent issues that I would never see until I actually ran it on the device, or emulator. Hopefully the differences between each platform's cordova.js is insignificant, but I don't think that we know this for sure.
The code to inject/intercept ANY platform's cordova.exec is simple, really, it is <10 lines.
In my mind, ripple should be responsible for hooking it's own way in, and proxying, without extra specific built in support either by cordova-browser, or cordova-js.
@purplecabbage
risingj.com
On Tue, Nov 18, 2014 at 11:49 AM, Michal Mocny <mm...@chromium.org> wrote:
> Serge,
>
> That sounds like you disagree with Julian's earlier summary that
> Ripple should just intersect at the exec proxy level, and propose
> instead that Ripple should intersect by having "hooks" inside the
> cordova-browser plugin js-modules, correct?
>
> I think thats not impossible (plugin authors can do what they want),
> but perhaps should just happen on a case-by-case basis, as required.
> If you have ideas about an architecture that we should advise
> developers to use by default, I'm curious what that would even look like.
>
> -Michal
>
> On Tue, Nov 18, 2014 at 1:01 PM, Lunev, Serge <se...@intel.com>
> wrote:
>
> > Let me add two pennies from my side also then :)
> >
> > From the community perspective, I have little hope that a random
> > plugin author will care about anything beyond browser target for
> > his/her plugin for testing/debug purposes. I do think though that
> > putting a right architecture in place for something better than a
> > regular browser target can provide is important. 'Something better'
> > means here a way to hook up browser developer tools (or Ripple /
> > node-webkit combo in Intel XDK case) to control plugin behavior so
> > that input data could be controlled by appropriate UI in browser/XDK.
> >
> > For us in XDK the alternative would be to fully separate a plugin
> > from
> its
> > emulation. I.e. if we choose to support certain plugin emulation in
> > the XDK, that will be totally technically separate from its Cordova
> > implementation. While this is a viable alternative, this just
> > doesn't
> smell
> > right.
> >
> > Best,
> > Serge Lunev
> > Intel XDK Engineering Manager
> > @lunarserge
> >
> > -----Original Message-----
> > From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On
> > Behalf
> Of
> > Brian LeRoux
> > Sent: Tuesday, November 18, 2014 9:26 AM
> > To: dev@cordova.apache.org
> > Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
> >
> > I'm less interested in copying work being done faster/better in the
> > browser devtools. Certainly some UI abstractions are helpful (map
> controls,
> > acceleromter scrubbing widget, etc) but the returns for dev time are
> > diminishing for the effort to author/maintain. Esp bad considering
> > we'd have to pick UI paradigms and enforce them somehow.
> >
> > For my two pennies, providing an abstraction that allows authoring
> > time convenience of using browser with an eventual goal for open web
> publishing
> > would be the best architecture (and strategy) for Cordova to pursue.
> >
> > On Tue, Nov 18, 2014 at 9:12 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> > > On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden <ra...@adobe.com>
> wrote:
> > >
> > > >
> > > > >>
> > > > >> On 11/15/14, 2:17 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> > > > >>
> > > >
> > > > >>Not at all. What is it you think we are proposing? I'm
> > > > >>merely suggesting
> > > > >that the cordova-browser camera plugin implementation shouldn't
> > > > >*also* come with a DOM component that sits over top of your
> > > > >application to
> > > manipulate
> > > > >the camera. The existing BAAP camera implementation is great
> > > > >as
> > > currently
> > > > >implemented, and wouldn't change.
> > > > >
> > > > >Another example would better illustrate the difference: BAAP
> > > > >geolocation shim I believe should just use the browser
> > > > >geolocation api, or return a single fixed location if that
> > > > >isn't available. It needn't support programmatically / UI for
> > > > >manipulating custom location, which Ripple geolocation does.
> > > >
> > > > I’m with you on that - but I think that is an example that works
> > > > well w/o UI and other plugins may not. Let’s consider contacts,
> > > > specifically pickContact. I *would* be ok with a UI of some
> > > > sort, perhaps just 3
> > > simple
> > > > contacts in a list, that that user can select. In theory it
> > > > could also just automatically fire contactSuccess, but my point
> > > > is that I’m not opposed to it providing a bit of UI as well.
> > > >
> > > >
> > > > >>As an example, I¹ve got an app now which uses barcode scanning
> > > > >>for one small part. By adding the Browser platform to the
> > > > >>plugin, I am able to do all of my work in the browser now and
> > > > >>fake a barcode when I need it.
> > > > >>That
> > > > >> is a problem that - imo - is much more valuable than
> > > > >>supporting
> > > browser
> > > > >>as
> > > > >> a destination of my app.
> > > > >>
> > > > >
> > > > >If you just want to return a single fixed barcode, I agree BAAP
> > > > >should
> > > do
> > > > >this. If you want to be able to customize the barcode at
> > > > >runtime, with
> > > a
> > > > >simple UI that is automatically injected into your page as part
> > > > >of the runtime, then I think that is a task for Ripple (or
> > > > >other
> > emulators).
> > > >
> > > >
> > > > So I think this is the crux of our disagreement then. :) Right
> > > > now the plugin (and I wrote this, so I may be biased ;) uses a
> > > > prompt so you can enter a code. My thinking there was if you
> > > > didn’t care, you would type 1 and hit enter, but if you were
> > > > passing the bar code to some service, you could paste something
> > > > in. To me, that’s more useful then just using a
> > > hard
> > > > coded value you can’t tweak. I think that usefulness outweighs
> > > > the potential ‘loss’ of being able to run this as a real web app.
> > > >
> > >
> > > Fair enough. Sounds like you want some of what I've proposed
> > > Ripple could offer, but are concerned that Ripple won't be a
> > > viable/sustainable choice for you. To be honest, I share that concern.
> > >
> > > For the barcode scanning example, I think a popup with an input
> > > box is fine, even for prod, so long as the popup is presented as
> > > if to a user and not as if to a developer. Hopefully we can
> > > improve it to also offer an input type=image, or to use the webcam
> > > (I haven't looked, not sure if it does this yet).
> > >
> > > If we really want separate dev mode and prod mode for a given
> > > plugin, perhaps we can just add an api for toggle this. I just
> > > hope to set the precedent that the default isn't *just* for developer debugging.
> > >
> > > -Michal
> > >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
Re: Summarizing thoughts on cordova-browser vs Ripple
Posted by Jesse <pu...@gmail.com>.
Shouldn't ripple be able to emulate/monkey-patch any of the platforms?
If I am looking at and testing my cordova-ios app in ripple, I think I
would want the cordova-ios.js to be run, and not cordova-browser.js,
otherwise there could be latent issues that I would never see until I
actually ran it on the device, or emulator. Hopefully the differences
between each platform's cordova.js is insignificant, but I don't think that
we know this for sure.
The code to inject/intercept ANY platform's cordova.exec is simple, really,
it is <10 lines.
In my mind, ripple should be responsible for hooking it's own way in, and
proxying, without extra specific built in support either by
cordova-browser, or cordova-js.
@purplecabbage
risingj.com
On Tue, Nov 18, 2014 at 11:49 AM, Michal Mocny <mm...@chromium.org> wrote:
> Serge,
>
> That sounds like you disagree with Julian's earlier summary that Ripple
> should just intersect at the exec proxy level, and propose instead that
> Ripple should intersect by having "hooks" inside the cordova-browser plugin
> js-modules, correct?
>
> I think thats not impossible (plugin authors can do what they want), but
> perhaps should just happen on a case-by-case basis, as required. If you
> have ideas about an architecture that we should advise developers to use by
> default, I'm curious what that would even look like.
>
> -Michal
>
> On Tue, Nov 18, 2014 at 1:01 PM, Lunev, Serge <se...@intel.com>
> wrote:
>
> > Let me add two pennies from my side also then :)
> >
> > From the community perspective, I have little hope that a random plugin
> > author will care about anything beyond browser target for his/her plugin
> > for testing/debug purposes. I do think though that putting a right
> > architecture in place for something better than a regular browser target
> > can provide is important. 'Something better' means here a way to hook up
> > browser developer tools (or Ripple / node-webkit combo in Intel XDK case)
> > to control plugin behavior so that input data could be controlled by
> > appropriate UI in browser/XDK.
> >
> > For us in XDK the alternative would be to fully separate a plugin from
> its
> > emulation. I.e. if we choose to support certain plugin emulation in the
> > XDK, that will be totally technically separate from its Cordova
> > implementation. While this is a viable alternative, this just doesn't
> smell
> > right.
> >
> > Best,
> > Serge Lunev
> > Intel XDK Engineering Manager
> > @lunarserge
> >
> > -----Original Message-----
> > From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf
> Of
> > Brian LeRoux
> > Sent: Tuesday, November 18, 2014 9:26 AM
> > To: dev@cordova.apache.org
> > Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
> >
> > I'm less interested in copying work being done faster/better in the
> > browser devtools. Certainly some UI abstractions are helpful (map
> controls,
> > acceleromter scrubbing widget, etc) but the returns for dev time are
> > diminishing for the effort to author/maintain. Esp bad considering we'd
> > have to pick UI paradigms and enforce them somehow.
> >
> > For my two pennies, providing an abstraction that allows authoring time
> > convenience of using browser with an eventual goal for open web
> publishing
> > would be the best architecture (and strategy) for Cordova to pursue.
> >
> > On Tue, Nov 18, 2014 at 9:12 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> > > On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden <ra...@adobe.com>
> wrote:
> > >
> > > >
> > > > >>
> > > > >> On 11/15/14, 2:17 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> > > > >>
> > > >
> > > > >>Not at all. What is it you think we are proposing? I'm merely
> > > > >>suggesting
> > > > >that the cordova-browser camera plugin implementation shouldn't
> > > > >*also* come with a DOM component that sits over top of your
> > > > >application to
> > > manipulate
> > > > >the camera. The existing BAAP camera implementation is great as
> > > currently
> > > > >implemented, and wouldn't change.
> > > > >
> > > > >Another example would better illustrate the difference: BAAP
> > > > >geolocation shim I believe should just use the browser geolocation
> > > > >api, or return a single fixed location if that isn't available. It
> > > > >needn't support programmatically / UI for manipulating custom
> > > > >location, which Ripple geolocation does.
> > > >
> > > > I’m with you on that - but I think that is an example that works
> > > > well w/o UI and other plugins may not. Let’s consider contacts,
> > > > specifically pickContact. I *would* be ok with a UI of some sort,
> > > > perhaps just 3
> > > simple
> > > > contacts in a list, that that user can select. In theory it could
> > > > also just automatically fire contactSuccess, but my point is that
> > > > I’m not opposed to it providing a bit of UI as well.
> > > >
> > > >
> > > > >>As an example, I¹ve got an app now which uses barcode scanning for
> > > > >>one small part. By adding the Browser platform to the plugin, I
> > > > >>am able to do all of my work in the browser now and fake a
> > > > >>barcode when I need it.
> > > > >>That
> > > > >> is a problem that - imo - is much more valuable than supporting
> > > browser
> > > > >>as
> > > > >> a destination of my app.
> > > > >>
> > > > >
> > > > >If you just want to return a single fixed barcode, I agree BAAP
> > > > >should
> > > do
> > > > >this. If you want to be able to customize the barcode at runtime,
> > > > >with
> > > a
> > > > >simple UI that is automatically injected into your page as part of
> > > > >the runtime, then I think that is a task for Ripple (or other
> > emulators).
> > > >
> > > >
> > > > So I think this is the crux of our disagreement then. :) Right now
> > > > the plugin (and I wrote this, so I may be biased ;) uses a prompt so
> > > > you can enter a code. My thinking there was if you didn’t care, you
> > > > would type 1 and hit enter, but if you were passing the bar code to
> > > > some service, you could paste something in. To me, that’s more
> > > > useful then just using a
> > > hard
> > > > coded value you can’t tweak. I think that usefulness outweighs the
> > > > potential ‘loss’ of being able to run this as a real web app.
> > > >
> > >
> > > Fair enough. Sounds like you want some of what I've proposed Ripple
> > > could offer, but are concerned that Ripple won't be a
> > > viable/sustainable choice for you. To be honest, I share that concern.
> > >
> > > For the barcode scanning example, I think a popup with an input box is
> > > fine, even for prod, so long as the popup is presented as if to a user
> > > and not as if to a developer. Hopefully we can improve it to also
> > > offer an input type=image, or to use the webcam (I haven't looked, not
> > > sure if it does this yet).
> > >
> > > If we really want separate dev mode and prod mode for a given plugin,
> > > perhaps we can just add an api for toggle this. I just hope to set
> > > the precedent that the default isn't *just* for developer debugging.
> > >
> > > -Michal
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
Re: Summarizing thoughts on cordova-browser vs Ripple
Posted by Michal Mocny <mm...@chromium.org>.
Serge,
That sounds like you disagree with Julian's earlier summary that Ripple
should just intersect at the exec proxy level, and propose instead that
Ripple should intersect by having "hooks" inside the cordova-browser plugin
js-modules, correct?
I think thats not impossible (plugin authors can do what they want), but
perhaps should just happen on a case-by-case basis, as required. If you
have ideas about an architecture that we should advise developers to use by
default, I'm curious what that would even look like.
-Michal
On Tue, Nov 18, 2014 at 1:01 PM, Lunev, Serge <se...@intel.com> wrote:
> Let me add two pennies from my side also then :)
>
> From the community perspective, I have little hope that a random plugin
> author will care about anything beyond browser target for his/her plugin
> for testing/debug purposes. I do think though that putting a right
> architecture in place for something better than a regular browser target
> can provide is important. 'Something better' means here a way to hook up
> browser developer tools (or Ripple / node-webkit combo in Intel XDK case)
> to control plugin behavior so that input data could be controlled by
> appropriate UI in browser/XDK.
>
> For us in XDK the alternative would be to fully separate a plugin from its
> emulation. I.e. if we choose to support certain plugin emulation in the
> XDK, that will be totally technically separate from its Cordova
> implementation. While this is a viable alternative, this just doesn't smell
> right.
>
> Best,
> Serge Lunev
> Intel XDK Engineering Manager
> @lunarserge
>
> -----Original Message-----
> From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf Of
> Brian LeRoux
> Sent: Tuesday, November 18, 2014 9:26 AM
> To: dev@cordova.apache.org
> Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
>
> I'm less interested in copying work being done faster/better in the
> browser devtools. Certainly some UI abstractions are helpful (map controls,
> acceleromter scrubbing widget, etc) but the returns for dev time are
> diminishing for the effort to author/maintain. Esp bad considering we'd
> have to pick UI paradigms and enforce them somehow.
>
> For my two pennies, providing an abstraction that allows authoring time
> convenience of using browser with an eventual goal for open web publishing
> would be the best architecture (and strategy) for Cordova to pursue.
>
> On Tue, Nov 18, 2014 at 9:12 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden <ra...@adobe.com> wrote:
> >
> > >
> > > >>
> > > >> On 11/15/14, 2:17 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> > > >>
> > >
> > > >>Not at all. What is it you think we are proposing? I'm merely
> > > >>suggesting
> > > >that the cordova-browser camera plugin implementation shouldn't
> > > >*also* come with a DOM component that sits over top of your
> > > >application to
> > manipulate
> > > >the camera. The existing BAAP camera implementation is great as
> > currently
> > > >implemented, and wouldn't change.
> > > >
> > > >Another example would better illustrate the difference: BAAP
> > > >geolocation shim I believe should just use the browser geolocation
> > > >api, or return a single fixed location if that isn't available. It
> > > >needn't support programmatically / UI for manipulating custom
> > > >location, which Ripple geolocation does.
> > >
> > > I’m with you on that - but I think that is an example that works
> > > well w/o UI and other plugins may not. Let’s consider contacts,
> > > specifically pickContact. I *would* be ok with a UI of some sort,
> > > perhaps just 3
> > simple
> > > contacts in a list, that that user can select. In theory it could
> > > also just automatically fire contactSuccess, but my point is that
> > > I’m not opposed to it providing a bit of UI as well.
> > >
> > >
> > > >>As an example, I¹ve got an app now which uses barcode scanning for
> > > >>one small part. By adding the Browser platform to the plugin, I
> > > >>am able to do all of my work in the browser now and fake a
> > > >>barcode when I need it.
> > > >>That
> > > >> is a problem that - imo - is much more valuable than supporting
> > browser
> > > >>as
> > > >> a destination of my app.
> > > >>
> > > >
> > > >If you just want to return a single fixed barcode, I agree BAAP
> > > >should
> > do
> > > >this. If you want to be able to customize the barcode at runtime,
> > > >with
> > a
> > > >simple UI that is automatically injected into your page as part of
> > > >the runtime, then I think that is a task for Ripple (or other
> emulators).
> > >
> > >
> > > So I think this is the crux of our disagreement then. :) Right now
> > > the plugin (and I wrote this, so I may be biased ;) uses a prompt so
> > > you can enter a code. My thinking there was if you didn’t care, you
> > > would type 1 and hit enter, but if you were passing the bar code to
> > > some service, you could paste something in. To me, that’s more
> > > useful then just using a
> > hard
> > > coded value you can’t tweak. I think that usefulness outweighs the
> > > potential ‘loss’ of being able to run this as a real web app.
> > >
> >
> > Fair enough. Sounds like you want some of what I've proposed Ripple
> > could offer, but are concerned that Ripple won't be a
> > viable/sustainable choice for you. To be honest, I share that concern.
> >
> > For the barcode scanning example, I think a popup with an input box is
> > fine, even for prod, so long as the popup is presented as if to a user
> > and not as if to a developer. Hopefully we can improve it to also
> > offer an input type=image, or to use the webcam (I haven't looked, not
> > sure if it does this yet).
> >
> > If we really want separate dev mode and prod mode for a given plugin,
> > perhaps we can just add an api for toggle this. I just hope to set
> > the precedent that the default isn't *just* for developer debugging.
> >
> > -Michal
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
RE: Summarizing thoughts on cordova-browser vs Ripple
Posted by "Lunev, Serge" <se...@intel.com>.
Let me add two pennies from my side also then :)
From the community perspective, I have little hope that a random plugin author will care about anything beyond browser target for his/her plugin for testing/debug purposes. I do think though that putting a right architecture in place for something better than a regular browser target can provide is important. 'Something better' means here a way to hook up browser developer tools (or Ripple / node-webkit combo in Intel XDK case) to control plugin behavior so that input data could be controlled by appropriate UI in browser/XDK.
For us in XDK the alternative would be to fully separate a plugin from its emulation. I.e. if we choose to support certain plugin emulation in the XDK, that will be totally technically separate from its Cordova implementation. While this is a viable alternative, this just doesn't smell right.
Best,
Serge Lunev
Intel XDK Engineering Manager
@lunarserge
-----Original Message-----
From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf Of Brian LeRoux
Sent: Tuesday, November 18, 2014 9:26 AM
To: dev@cordova.apache.org
Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
I'm less interested in copying work being done faster/better in the browser devtools. Certainly some UI abstractions are helpful (map controls, acceleromter scrubbing widget, etc) but the returns for dev time are diminishing for the effort to author/maintain. Esp bad considering we'd have to pick UI paradigms and enforce them somehow.
For my two pennies, providing an abstraction that allows authoring time convenience of using browser with an eventual goal for open web publishing would be the best architecture (and strategy) for Cordova to pursue.
On Tue, Nov 18, 2014 at 9:12 AM, Michal Mocny <mm...@chromium.org> wrote:
> On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden <ra...@adobe.com> wrote:
>
> >
> > >>
> > >> On 11/15/14, 2:17 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> > >>
> >
> > >>Not at all. What is it you think we are proposing? I'm merely
> > >>suggesting
> > >that the cordova-browser camera plugin implementation shouldn't
> > >*also* come with a DOM component that sits over top of your
> > >application to
> manipulate
> > >the camera. The existing BAAP camera implementation is great as
> currently
> > >implemented, and wouldn't change.
> > >
> > >Another example would better illustrate the difference: BAAP
> > >geolocation shim I believe should just use the browser geolocation
> > >api, or return a single fixed location if that isn't available. It
> > >needn't support programmatically / UI for manipulating custom
> > >location, which Ripple geolocation does.
> >
> > I’m with you on that - but I think that is an example that works
> > well w/o UI and other plugins may not. Let’s consider contacts,
> > specifically pickContact. I *would* be ok with a UI of some sort,
> > perhaps just 3
> simple
> > contacts in a list, that that user can select. In theory it could
> > also just automatically fire contactSuccess, but my point is that
> > I’m not opposed to it providing a bit of UI as well.
> >
> >
> > >>As an example, I¹ve got an app now which uses barcode scanning for
> > >>one small part. By adding the Browser platform to the plugin, I
> > >>am able to do all of my work in the browser now and fake a
> > >>barcode when I need it.
> > >>That
> > >> is a problem that - imo - is much more valuable than supporting
> browser
> > >>as
> > >> a destination of my app.
> > >>
> > >
> > >If you just want to return a single fixed barcode, I agree BAAP
> > >should
> do
> > >this. If you want to be able to customize the barcode at runtime,
> > >with
> a
> > >simple UI that is automatically injected into your page as part of
> > >the runtime, then I think that is a task for Ripple (or other emulators).
> >
> >
> > So I think this is the crux of our disagreement then. :) Right now
> > the plugin (and I wrote this, so I may be biased ;) uses a prompt so
> > you can enter a code. My thinking there was if you didn’t care, you
> > would type 1 and hit enter, but if you were passing the bar code to
> > some service, you could paste something in. To me, that’s more
> > useful then just using a
> hard
> > coded value you can’t tweak. I think that usefulness outweighs the
> > potential ‘loss’ of being able to run this as a real web app.
> >
>
> Fair enough. Sounds like you want some of what I've proposed Ripple
> could offer, but are concerned that Ripple won't be a
> viable/sustainable choice for you. To be honest, I share that concern.
>
> For the barcode scanning example, I think a popup with an input box is
> fine, even for prod, so long as the popup is presented as if to a user
> and not as if to a developer. Hopefully we can improve it to also
> offer an input type=image, or to use the webcam (I haven't looked, not
> sure if it does this yet).
>
> If we really want separate dev mode and prod mode for a given plugin,
> perhaps we can just add an api for toggle this. I just hope to set
> the precedent that the default isn't *just* for developer debugging.
>
> -Michal
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Summarizing thoughts on cordova-browser vs Ripple
Posted by Brian LeRoux <b...@brian.io>.
I'm less interested in copying work being done faster/better in the browser
devtools. Certainly some UI abstractions are helpful (map controls,
acceleromter scrubbing widget, etc) but the returns for dev time are
diminishing for the effort to author/maintain. Esp bad considering we'd
have to pick UI paradigms and enforce them somehow.
For my two pennies, providing an abstraction that allows authoring time
convenience of using browser with an eventual goal for open web publishing
would be the best architecture (and strategy) for Cordova to pursue.
On Tue, Nov 18, 2014 at 9:12 AM, Michal Mocny <mm...@chromium.org> wrote:
> On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden <ra...@adobe.com> wrote:
>
> >
> > >>
> > >> On 11/15/14, 2:17 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> > >>
> >
> > >>Not at all. What is it you think we are proposing? I'm merely
> > >>suggesting
> > >that the cordova-browser camera plugin implementation shouldn't *also*
> > >come
> > >with a DOM component that sits over top of your application to
> manipulate
> > >the camera. The existing BAAP camera implementation is great as
> currently
> > >implemented, and wouldn't change.
> > >
> > >Another example would better illustrate the difference: BAAP geolocation
> > >shim I believe should just use the browser geolocation api, or return a
> > >single fixed location if that isn't available. It needn't support
> > >programmatically / UI for manipulating custom location, which Ripple
> > >geolocation does.
> >
> > I’m with you on that - but I think that is an example that works well w/o
> > UI and other plugins may not. Let’s consider contacts, specifically
> > pickContact. I *would* be ok with a UI of some sort, perhaps just 3
> simple
> > contacts in a list, that that user can select. In theory it could also
> > just automatically fire contactSuccess, but my point is that I’m not
> > opposed to it providing a bit of UI as well.
> >
> >
> > >>As an example, I¹ve got an app now which uses barcode scanning for one
> > >> small part. By adding the Browser platform to the plugin, I am able to
> > >>do
> > >> all of my work in the browser now and fake a barcode when I need it.
> > >>That
> > >> is a problem that - imo - is much more valuable than supporting
> browser
> > >>as
> > >> a destination of my app.
> > >>
> > >
> > >If you just want to return a single fixed barcode, I agree BAAP should
> do
> > >this. If you want to be able to customize the barcode at runtime, with
> a
> > >simple UI that is automatically injected into your page as part of the
> > >runtime, then I think that is a task for Ripple (or other emulators).
> >
> >
> > So I think this is the crux of our disagreement then. :) Right now the
> > plugin (and I wrote this, so I may be biased ;) uses a prompt so you can
> > enter a code. My thinking there was if you didn’t care, you would type 1
> > and hit enter, but if you were passing the bar code to some service, you
> > could paste something in. To me, that’s more useful then just using a
> hard
> > coded value you can’t tweak. I think that usefulness outweighs the
> > potential ‘loss’ of being able to run this as a real web app.
> >
>
> Fair enough. Sounds like you want some of what I've proposed Ripple could
> offer, but are concerned that Ripple won't be a viable/sustainable choice
> for you. To be honest, I share that concern.
>
> For the barcode scanning example, I think a popup with an input box is
> fine, even for prod, so long as the popup is presented as if to a user and
> not as if to a developer. Hopefully we can improve it to also offer an
> input type=image, or to use the webcam (I haven't looked, not sure if it
> does this yet).
>
> If we really want separate dev mode and prod mode for a given plugin,
> perhaps we can just add an api for toggle this. I just hope to set the
> precedent that the default isn't *just* for developer debugging.
>
> -Michal
>
Re: Summarizing thoughts on cordova-browser vs Ripple
Posted by Michal Mocny <mm...@chromium.org>.
On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden <ra...@adobe.com> wrote:
>
> >>
> >> On 11/15/14, 2:17 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> >>
>
> >>Not at all. What is it you think we are proposing? I'm merely
> >>suggesting
> >that the cordova-browser camera plugin implementation shouldn't *also*
> >come
> >with a DOM component that sits over top of your application to manipulate
> >the camera. The existing BAAP camera implementation is great as currently
> >implemented, and wouldn't change.
> >
> >Another example would better illustrate the difference: BAAP geolocation
> >shim I believe should just use the browser geolocation api, or return a
> >single fixed location if that isn't available. It needn't support
> >programmatically / UI for manipulating custom location, which Ripple
> >geolocation does.
>
> I’m with you on that - but I think that is an example that works well w/o
> UI and other plugins may not. Let’s consider contacts, specifically
> pickContact. I *would* be ok with a UI of some sort, perhaps just 3 simple
> contacts in a list, that that user can select. In theory it could also
> just automatically fire contactSuccess, but my point is that I’m not
> opposed to it providing a bit of UI as well.
>
>
> >>As an example, I¹ve got an app now which uses barcode scanning for one
> >> small part. By adding the Browser platform to the plugin, I am able to
> >>do
> >> all of my work in the browser now and fake a barcode when I need it.
> >>That
> >> is a problem that - imo - is much more valuable than supporting browser
> >>as
> >> a destination of my app.
> >>
> >
> >If you just want to return a single fixed barcode, I agree BAAP should do
> >this. If you want to be able to customize the barcode at runtime, with a
> >simple UI that is automatically injected into your page as part of the
> >runtime, then I think that is a task for Ripple (or other emulators).
>
>
> So I think this is the crux of our disagreement then. :) Right now the
> plugin (and I wrote this, so I may be biased ;) uses a prompt so you can
> enter a code. My thinking there was if you didn’t care, you would type 1
> and hit enter, but if you were passing the bar code to some service, you
> could paste something in. To me, that’s more useful then just using a hard
> coded value you can’t tweak. I think that usefulness outweighs the
> potential ‘loss’ of being able to run this as a real web app.
>
Fair enough. Sounds like you want some of what I've proposed Ripple could
offer, but are concerned that Ripple won't be a viable/sustainable choice
for you. To be honest, I share that concern.
For the barcode scanning example, I think a popup with an input box is
fine, even for prod, so long as the popup is presented as if to a user and
not as if to a developer. Hopefully we can improve it to also offer an
input type=image, or to use the webcam (I haven't looked, not sure if it
does this yet).
If we really want separate dev mode and prod mode for a given plugin,
perhaps we can just add an api for toggle this. I just hope to set the
precedent that the default isn't *just* for developer debugging.
-Michal
Re: Summarizing thoughts on cordova-browser vs Ripple
Posted by Ray Camden <ra...@adobe.com>.
>>
>> On 11/15/14, 2:17 PM, "Michal Mocny" <mm...@chromium.org> wrote:
>>
>>Not at all. What is it you think we are proposing? I'm merely
>>suggesting
>that the cordova-browser camera plugin implementation shouldn't *also*
>come
>with a DOM component that sits over top of your application to manipulate
>the camera. The existing BAAP camera implementation is great as currently
>implemented, and wouldn't change.
>
>Another example would better illustrate the difference: BAAP geolocation
>shim I believe should just use the browser geolocation api, or return a
>single fixed location if that isn't available. It needn't support
>programmatically / UI for manipulating custom location, which Ripple
>geolocation does.
I’m with you on that - but I think that is an example that works well w/o
UI and other plugins may not. Let’s consider contacts, specifically
pickContact. I *would* be ok with a UI of some sort, perhaps just 3 simple
contacts in a list, that that user can select. In theory it could also
just automatically fire contactSuccess, but my point is that I’m not
opposed to it providing a bit of UI as well.
>>As an example, I¹ve got an app now which uses barcode scanning for one
>> small part. By adding the Browser platform to the plugin, I am able to
>>do
>> all of my work in the browser now and fake a barcode when I need it.
>>That
>> is a problem that - imo - is much more valuable than supporting browser
>>as
>> a destination of my app.
>>
>
>If you just want to return a single fixed barcode, I agree BAAP should do
>this. If you want to be able to customize the barcode at runtime, with a
>simple UI that is automatically injected into your page as part of the
>runtime, then I think that is a task for Ripple (or other emulators).
So I think this is the crux of our disagreement then. :) Right now the
plugin (and I wrote this, so I may be biased ;) uses a prompt so you can
enter a code. My thinking there was if you didn’t care, you would type 1
and hit enter, but if you were passing the bar code to some service, you
could paste something in. To me, that’s more useful then just using a hard
coded value you can’t tweak. I think that usefulness outweighs the
potential ‘loss’ of being able to run this as a real web app.
Re: Summarizing thoughts on cordova-browser vs Ripple
Posted by Michal Mocny <mm...@chromium.org>.
On Mon, Nov 17, 2014 at 6:37 AM, Ray Camden <ra...@adobe.com> wrote:
>
>
> On 11/15/14, 2:17 PM, "Michal Mocny" <mm...@chromium.org> wrote:
>
> >Ray, I think (hope) you are slightly misreading the distinction. Trying
> >to
> >rephrase:
> >
> >Ripple is an (optional) tool for mobile-device-emulation. It just happens
> >to be implemented in a browser, and yes has historically been used by devs
> >to run cordova apps locally in a browser. But ripple does a lot more than
> >some devs need/want. We want to take all those extras out for
> >cordova-browser, and leave them in for Ripple.
>
> I disagree completely. ³just so happens to be implemented in a browser²
> makes it sound like a random thing. Ripple was a way to make use of the
> speed of a browser to run my PG/Cordova apps while Œfaking¹ stuff like
> camera and GPS. It let me focus on the non-Cordova stuff, like random APIs
> (especially since it lets me bypass the remote XHR restriction w/o CORS).
>
> >Specifically, cordova-browser would provide a minimum valid cordova
> >environment & plugin browser shims, just so your app loads without errors
> >in a browser. There would not be any specific mobile device or platform
> >emulation. Many devs do this manually today (Adobe even presented on this
> >topic at PGDay), but cordova-browser will automate some of the work now.
>
>
> And I strongly vote against this. The fact that I can fake camera w/ BAAP
> now and not rely on Ripple, which again was dead for like a *year*, is a
> huge big deal to me, and I¹d argue others as well.
>
> It sounds like we are saying we should take BAAP, which has the beginnings
> of a good Ripple replacement, and neuter it, which I think would be
> horrible.
>
Not at all. What is it you think we are proposing? I'm merely suggesting
that the cordova-browser camera plugin implementation shouldn't *also* come
with a DOM component that sits over top of your application to manipulate
the camera. The existing BAAP camera implementation is great as currently
implemented, and wouldn't change.
Another example would better illustrate the difference: BAAP geolocation
shim I believe should just use the browser geolocation api, or return a
single fixed location if that isn't available. It needn't support
programmatically / UI for manipulating custom location, which Ripple
geolocation does.
>
> >
> >What you do with the browser targeted version of your application is up to
> >you. Some developers won't use it at all, others may use it for rapid
> >development on a subset of the app, while others may use it to actually
> >publically host for the mobile web. I'm not necessarily sure if that last
> >point is a great idea, but I'm convinced we shouldn't get in the way of
> >others trying. (Ray, if you don't want the public to use your app from a
> >browser, just don't host it, that will be your call to make).
>
> I guess this is the main sticking point then. It sounds like you are
> saying we should support browser as a complete platform, and having the
> plugins do too much will be a problem. I think there is a chance folks may
> want BAAP to be used publicly, but I think a good debugging alternative
> would be *much more* desired.
>
I previously used this argument as well, but didn't have concrete examples
of where optionally targeting prod harmed creating a good debugging
alternative. I agree that a good debugging env is the more important goal,
though not the only one. If there are valid examples where these goals are
at odds, we need to surface them.
>
> As an example, I¹ve got an app now which uses barcode scanning for one
> small part. By adding the Browser platform to the plugin, I am able to do
> all of my work in the browser now and fake a barcode when I need it. That
> is a problem that - imo - is much more valuable than supporting browser as
> a destination of my app.
>
If you just want to return a single fixed barcode, I agree BAAP should do
this. If you want to be able to customize the barcode at runtime, with a
simple UI that is automatically injected into your page as part of the
runtime, then I think that is a task for Ripple (or other emulators).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: Summarizing thoughts on cordova-browser vs Ripple
Posted by Ray Camden <ra...@adobe.com>.
On 11/15/14, 2:17 PM, "Michal Mocny" <mm...@chromium.org> wrote:
>Ray, I think (hope) you are slightly misreading the distinction. Trying
>to
>rephrase:
>
>Ripple is an (optional) tool for mobile-device-emulation. It just happens
>to be implemented in a browser, and yes has historically been used by devs
>to run cordova apps locally in a browser. But ripple does a lot more than
>some devs need/want. We want to take all those extras out for
>cordova-browser, and leave them in for Ripple.
I disagree completely. ³just so happens to be implemented in a browser²
makes it sound like a random thing. Ripple was a way to make use of the
speed of a browser to run my PG/Cordova apps while Œfaking¹ stuff like
camera and GPS. It let me focus on the non-Cordova stuff, like random APIs
(especially since it lets me bypass the remote XHR restriction w/o CORS).
>Specifically, cordova-browser would provide a minimum valid cordova
>environment & plugin browser shims, just so your app loads without errors
>in a browser. There would not be any specific mobile device or platform
>emulation. Many devs do this manually today (Adobe even presented on this
>topic at PGDay), but cordova-browser will automate some of the work now.
And I strongly vote against this. The fact that I can fake camera w/ BAAP
now and not rely on Ripple, which again was dead for like a *year*, is a
huge big deal to me, and I¹d argue others as well.
It sounds like we are saying we should take BAAP, which has the beginnings
of a good Ripple replacement, and neuter it, which I think would be
horrible.
>
>What you do with the browser targeted version of your application is up to
>you. Some developers won't use it at all, others may use it for rapid
>development on a subset of the app, while others may use it to actually
>publically host for the mobile web. I'm not necessarily sure if that last
>point is a great idea, but I'm convinced we shouldn't get in the way of
>others trying. (Ray, if you don't want the public to use your app from a
>browser, just don't host it, that will be your call to make).
I guess this is the main sticking point then. It sounds like you are
saying we should support browser as a complete platform, and having the
plugins do too much will be a problem. I think there is a chance folks may
want BAAP to be used publicly, but I think a good debugging alternative
would be *much more* desired.
As an example, I¹ve got an app now which uses barcode scanning for one
small part. By adding the Browser platform to the plugin, I am able to do
all of my work in the browser now and fake a barcode when I need it. That
is a problem that - imo - is much more valuable than supporting browser as
a destination of my app.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Summarizing thoughts on cordova-browser vs Ripple
Posted by Michal Mocny <mm...@chromium.org>.
Ray, I think (hope) you are slightly misreading the distinction. Trying to
rephrase:
Ripple is an (optional) tool for mobile-device-emulation. It just happens
to be implemented in a browser, and yes has historically been used by devs
to run cordova apps locally in a browser. But ripple does a lot more than
some devs need/want. We want to take all those extras out for
cordova-browser, and leave them in for Ripple.
Specifically, cordova-browser would provide a minimum valid cordova
environment & plugin browser shims, just so your app loads without errors
in a browser. There would not be any specific mobile device or platform
emulation. Many devs do this manually today (Adobe even presented on this
topic at PGDay), but cordova-browser will automate some of the work now.
For Ripple, which alongside device emulation has been implementing cordova
plugin shims, the cordova-browser platform gives a new fallback option for
plugin implementation. When/how to do use these fallbacks is up to the
discretion of the Ripple maintainers, and needn't really be our concern. I
would advise that they fallback for all plugins that they aren't adding
debugging value for, but not my call.
As a developer, you will now be able to run the cordova-browser version of
your app in your "browser" of choice:
- A local desktop browser (possibly with DevTools mobile-emulation turned
on, possibly with live-reload added).
- From the ripple emulator.
- From a browser running inside a mobile device emulator (e.g. the awesome
new Microsoft Android emulator even has device sensor manipulation built
in).
- From a browser running on a usb/network connected physical device.
- From a cordova based application-shell ("app-harness").
- ...
What you do with the browser targeted version of your application is up to
you. Some developers won't use it at all, others may use it for rapid
development on a subset of the app, while others may use it to actually
publically host for the mobile web. I'm not necessarily sure if that last
point is a great idea, but I'm convinced we shouldn't get in the way of
others trying. (Ray, if you don't want the public to use your app from a
browser, just don't host it, that will be your call to make).
Finally, I don't see a need for ripple platform implementations to ship
with plugins, nor have the Ripple maintainers signalled a need for this.
-Michal
On Fri, Nov 14, 2014 at 4:23 PM, Ray Camden <ra...@adobe.com> wrote:
> I¹m pretty late to responding to this thread, but I wanted to throw in a
> few comments. In the first msg, Michal Mocny said this:
>
> "Basically, browser-platform is for getting apps running in a browser (duh)
> with as much working functionality as possible. Its supposed to simplify
> the 'if cordova then dialog else alert' problem, so you can build even more
> of your app with just local development. Seemingly this could be used to
> make targeting both web and app even easier.
>
> Ripple is for instrumenting/debugging apps by manipulating plugins. Its
> about having a UI that reaches into geolocation or camera and controls what
> the plugin returns to the app. Its about re-running the same device events
> over and over for tracking application logic changes.²
>
> I could not disagree with the second part more. I can tell you that from
> my experience, the casual end user/PG developer did not see Ripple as any
> different from what you described in the first paragraph. Maybe I¹m not
> reading you right, but I honestly don¹t think most users of Ripple saw it
> as anything but a way to test your code in the browser.
>
> Michael Brooks said:
> "Ideally, the Browser Platform is a production deployment environment for
> the web, while Ripple is debugging instrumentation that runs on the Browser
> Platform.²
>
> Again, I just don¹t see this. ³Production deployment²? As in - it is used
> by the public? I don¹t think our users will see that. I don¹t want the
> public to use my PG/Cordova app in the browser. I, the developer, want to
> use the browser just because it is quicker and the debugging tool is
> better.
>
> Kirupa said:
> "Cordova-browser shouldn't be responsible for providing mock data, UI, or
> any additional functionality for simulating a plug-in. It¹s primary goal
> is to (as you both mention) be responsible for getting apps to run in the
> browser.²
>
> I love Ripple, butŠ
> It was dead for a *very* long time. It has come back, and there is
> activity, but I¹m not convinced it will carry on. (Don¹t get me wrong, I
> want it to!) BAAP (I¹m using that for Browser As A Platform, much easier
> to type ;) is baked into Cordova and ³just plain works² once a plugin
> author adds support. It isn¹t an external tool - it is part of the core
> functionality. I think then that if it makes sense for a plugin to do UI,
> then BAAP should do it. I see no reason not too. Since the only one seeing
> it is the developer, then this UI, or mock data, can be simple and direct.
> If it lets me run my app quickly in the browser, then it doesn¹t have to
> be production-ready, just dev-ready.
>
> Andrew said:
> "From reading this, seems like it could work well to have plugins provide
> both browser and ripple implementations. They could make them the same, or
> have the ripple one provide some sort of nice emulation UI. e.g.²
>
> I see that as unlikely myself. If I were to write a plugin (I¹ll be
> honest, I haven¹t yet), I can¹t imagine doing the same thing twice for
> both, especially with how little movement has been done in Ripple. As a
> feature, isn¹t it fair to say BAAP is ³done²? I mean it needs support from
> more plugins, but as a feature, it is complete. I don¹t have to worry
> about it not working in the future as Ripple did.
>
> On 11/14/14, 12:38 PM, "Horn, Julian C" <ju...@intel.com> wrote:
>
> >Yes, that's absolutely right. The ripple and browser platforms can
> >coexist, and you can refer to the API implementations in the
> >cordova-browser platform from the ripple platform.
> >
> >You can imagine how this would work. The exec call should land in the
> >ripple implementation of the API. That code can decide whether it needs
> >to delegate to the browser implementation of the API. (It could use UI
> >to guide this decision.) If so, it finds the browser implementation via
> >execProxy and invokes it.
> >
> >This is easy when the ripple implementation is built in. Ripple's
> >implementation of "exec" separates the Services registered with Ripple
> >from those that self-register with execProxy. Ripple therefore can prefer
> >its own implementation when both exist. When the ripple and browser
> >implementations are both in the same plugin then you have a conflict
> >because both of them want to self-register as the same service. Still,
> >I'm confident that this can be sorted out.
> >
> >For example, say the JS part of a plugin calls exec for service S,
> >function F. The browser implementation self-registers with execProxy as
> >S. The ripple implementation could self-register as "Ripple S". When
> >asked to invoke a function in service "S", the Ripple exec function can
> >look for the object registered as "Ripple S" before looking for the
> >object registered as "S". Easy.
> >
> > Julian
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: Summarizing thoughts on cordova-browser vs Ripple
Posted by Ray Camden <ra...@adobe.com>.
I¹m pretty late to responding to this thread, but I wanted to throw in a
few comments. In the first msg, Michal Mocny said this:
"Basically, browser-platform is for getting apps running in a browser (duh)
with as much working functionality as possible. Its supposed to simplify
the 'if cordova then dialog else alert' problem, so you can build even more
of your app with just local development. Seemingly this could be used to
make targeting both web and app even easier.
Ripple is for instrumenting/debugging apps by manipulating plugins. Its
about having a UI that reaches into geolocation or camera and controls what
the plugin returns to the app. Its about re-running the same device events
over and over for tracking application logic changes.²
I could not disagree with the second part more. I can tell you that from
my experience, the casual end user/PG developer did not see Ripple as any
different from what you described in the first paragraph. Maybe I¹m not
reading you right, but I honestly don¹t think most users of Ripple saw it
as anything but a way to test your code in the browser.
Michael Brooks said:
"Ideally, the Browser Platform is a production deployment environment for
the web, while Ripple is debugging instrumentation that runs on the Browser
Platform.²
Again, I just don¹t see this. ³Production deployment²? As in - it is used
by the public? I don¹t think our users will see that. I don¹t want the
public to use my PG/Cordova app in the browser. I, the developer, want to
use the browser just because it is quicker and the debugging tool is
better.
Kirupa said:
"Cordova-browser shouldn't be responsible for providing mock data, UI, or
any additional functionality for simulating a plug-in. It¹s primary goal
is to (as you both mention) be responsible for getting apps to run in the
browser.²
I love Ripple, butŠ
It was dead for a *very* long time. It has come back, and there is
activity, but I¹m not convinced it will carry on. (Don¹t get me wrong, I
want it to!) BAAP (I¹m using that for Browser As A Platform, much easier
to type ;) is baked into Cordova and ³just plain works² once a plugin
author adds support. It isn¹t an external tool - it is part of the core
functionality. I think then that if it makes sense for a plugin to do UI,
then BAAP should do it. I see no reason not too. Since the only one seeing
it is the developer, then this UI, or mock data, can be simple and direct.
If it lets me run my app quickly in the browser, then it doesn¹t have to
be production-ready, just dev-ready.
Andrew said:
"From reading this, seems like it could work well to have plugins provide
both browser and ripple implementations. They could make them the same, or
have the ripple one provide some sort of nice emulation UI. e.g.²
I see that as unlikely myself. If I were to write a plugin (I¹ll be
honest, I haven¹t yet), I can¹t imagine doing the same thing twice for
both, especially with how little movement has been done in Ripple. As a
feature, isn¹t it fair to say BAAP is ³done²? I mean it needs support from
more plugins, but as a feature, it is complete. I don¹t have to worry
about it not working in the future as Ripple did.
On 11/14/14, 12:38 PM, "Horn, Julian C" <ju...@intel.com> wrote:
>Yes, that's absolutely right. The ripple and browser platforms can
>coexist, and you can refer to the API implementations in the
>cordova-browser platform from the ripple platform.
>
>You can imagine how this would work. The exec call should land in the
>ripple implementation of the API. That code can decide whether it needs
>to delegate to the browser implementation of the API. (It could use UI
>to guide this decision.) If so, it finds the browser implementation via
>execProxy and invokes it.
>
>This is easy when the ripple implementation is built in. Ripple's
>implementation of "exec" separates the Services registered with Ripple
>from those that self-register with execProxy. Ripple therefore can prefer
>its own implementation when both exist. When the ripple and browser
>implementations are both in the same plugin then you have a conflict
>because both of them want to self-register as the same service. Still,
>I'm confident that this can be sorted out.
>
>For example, say the JS part of a plugin calls exec for service S,
>function F. The browser implementation self-registers with execProxy as
>S. The ripple implementation could self-register as "Ripple S". When
>asked to invoke a function in service "S", the Ripple exec function can
>look for the object registered as "Ripple S" before looking for the
>object registered as "S". Easy.
>
> Julian
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
RE: Summarizing thoughts on cordova-browser vs Ripple
Posted by "Horn, Julian C" <ju...@intel.com>.
Yes, that's absolutely right. The ripple and browser platforms can coexist, and you can refer to the API implementations in the cordova-browser platform from the ripple platform.
You can imagine how this would work. The exec call should land in the ripple implementation of the API. That code can decide whether it needs to delegate to the browser implementation of the API. (It could use UI to guide this decision.) If so, it finds the browser implementation via execProxy and invokes it.
This is easy when the ripple implementation is built in. Ripple's implementation of "exec" separates the Services registered with Ripple from those that self-register with execProxy. Ripple therefore can prefer its own implementation when both exist. When the ripple and browser implementations are both in the same plugin then you have a conflict because both of them want to self-register as the same service. Still, I'm confident that this can be sorted out.
For example, say the JS part of a plugin calls exec for service S, function F. The browser implementation self-registers with execProxy as S. The ripple implementation could self-register as "Ripple S". When asked to invoke a function in service "S", the Ripple exec function can look for the object registered as "Ripple S" before looking for the object registered as "S". Easy.
Julian
-----Original Message-----
From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of Andrew Grieve
Sent: Friday, November 14, 2014 4:07 AM
To: dev
Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
From reading this, seems like it could work well to have plugins provide both browser and ripple implementations. They could make them the same, or have the ripple one provide some sort of nice emulation UI. e.g.
var div = ... createUI;
ripple.registerPluginUi(div)
Still also seems powerful though, to have Ripple be able to add UI for plugins that don't provide their own.
On Mon, Nov 10, 2014 at 3:48 PM, Michal Mocny <mm...@chromium.org> wrote:
> On Thu, Nov 6, 2014 at 6:52 PM, Horn, Julian C
> <ju...@intel.com>
> wrote:
>
> > I'd like to introduce myself and put in my two cents here. My name
> > is Julian Horn. I work for Intel on the XDK, an integrated
> > development environment for cross-platform HTML5 applications. I am
> > the team lead
> for
> > the Device Emulator component, which is our Ripple derivative. My
> > background is mostly in software development tools: compilers,
> > debuggers, simulators and analysis tools. I have been working with
> > the Ripple code base for a couple of years now.
> >
> > If I'm understanding the cordova-browser concept, the implementation
> > of a Cordova API for the browser platform should consist of code
> > that bridges between the platform-independent Cordova API and
> > whatever equivalent is available in the current browser session.
> > For example, the camera API getPicture function would invoke the
> > getUserMedia API, which is the
> closest
> > thing we have to a W3C standard way to take a picture. If the
> > browser doesn't implement this API or the host system doesn't have a
> > camera, then the getPicture call fails with "camera unavailable".
> >
> > This seems like a fine way to gradually migrate from packaged apps
> > that rely on native code plugins to pure web apps that rely on the
> > browser to access mobile device resources. This should work great
> > when you have a browser-portable implementation. It may be a
> > challenge with some
> plugins,
> > since of course Cordova/PhoneGap was designed to cover gaps in
> > browser support. But at least we don't have to wait for a real W3C
> > standard to
> be
> > agreed.
> >
> > The goal of our XDK product is to facilitate development of
> cross-platform
> > mobile HTML5 applications. We see the Device Emulator (our Ripple)
> > as enabling developers to test an HTML5 mobile application on the
> > host system. While this is no substitute for testing on real
> > hardware, the Device Emulator does offers some advantages that can
> > accelerate the development process. To summarize quickly:
> > * It’s really fast.
> > * You don't need an array of mobile devices.
> > * You can put off dealing with weird target system quirks until
> > after
> you
> > get your basic application logic debugged.
> > * You get full native JavaScript debugging, which is faster,
> > simpler,
> and
> > more available than remote debug.
> > * You can create testing situations that are difficult or
> > impossible to create in real life, such as GPS timeout.
> > * It's a great teaching tool.
> > * It allows you to prototype quickly.
> >
> > Assuming the functionality delivered by Ripple has value (and we
> > find it does), one needs a way to reconcile this with the cordova-browser effort.
> > Here's how I see that working out.
> >
> > One idea is to rely on the browser developer tools to supply
> > emulation support and just drop Ripple. I don't like this much.
> > Today the
> developer
> > tools emulation UI is fairly primitive, but of course, there is
> > nothing stopping the browser vendors from building all the
> > functionality in the Ripple Geolocation panel (or indeed all of
> > Ripple) into the developer tools. The bigger problem from my point
> > of view is that this is a closed system. There's no way for a
> > non-browser-vendor to extend the browser to provide emulation support for new plugin APIs.
> >
> > The alternative is to do a "cordova prepare browser" and load the
> > results into Ripple.
>
>
> This would be my preference if at all possible. Specifically, I think
> ripple would move much faster and be better architected if it didn't
> have to depend on making changes directly to cordova. Though it
> should be acceptable to create a ripple platform (cordova run ripple)
> if really need be.
>
>
> > Assuming the browser platform code follows the usual pattern, that
> > is, that it goes through an exec/execProxy layer, it should be
> > possible for Ripple to intercept at that level. Ripple can delegate
> > to the execProxy implementation if it has no emulation-time implementation of its own.
> This
> > means that unrecognized APIs run unaltered, in which case you get
> whatever
> > behavior you get on the browser platform. This is a really exciting
> > prospect. It's way better than that "we don't know what to do"
> > dialog
> that
> > Ripple puts up when an exec layer function it doesn't recognize is
> called.
> >
>
> Thats interesting. I hadn't considered doing it this way, but it
> actually sounds like a great solution.
>
>
> >
> > In fact there are some Cordova APIs that Ripple implements by mostly
> > delegating to a Chrome-specific API. For example, the simulation of
> > the Cordova File API is based on webkitRequestFileSystem.
> > (Unfortunately no other browser vendors have seen fit to support
> > this API.) In those
> cases I
> > think the Ripple implementation of the API is likely to coincide
> > nicely with the browser platform implementation.
> >
> > Unlike ripple-as-a-platform, this model doesn't allow plugin authors
> > to provide their own emulation-time solutions. I was always
> > skeptical that many plugin authors would really do this (others
> > disagree). But if they
> at
> > least provide a browser implementation then Ripple has something to
> > fall back on. And if there's something better that can be done, we
> > can always extend Ripple.
> >
>
> Given that the biggest benefit of Ripple is to provide UI to dig into
> and manually adjust the plugin behaviour, I share your sentiment. I
> did voice that I thought plugin authors would provide implementations
> -- but that is for what we know are classifying as cordova-browser
> implementations (even if just stubs / no-ops).
>
>
> >
> > Julian
> >
> > -----Original Message-----
> > From: Parashuram Narasimhan (MS OPEN TECH) [mailto:
> panarasi@microsoft.com]
> > Sent: Wednesday, November 05, 2014 2:25 PM
> > To: dev@cordova.apache.org
> > Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
> >
> > MSOpenTech is currently working on porting our ripple-platform
> > prototype
> -
> > https://github.com/MSOpenTech/cordova-ripple to work on top of
> > cordova-browser. The question on how each plugin exposes a UI to
> > provide mock data is still up for discussion, but Intel has a lot of
> > context on that area.
> >
> > -----Original Message-----
> > From: Kirupa Chinnathambi [mailto:kirupac@microsoft.com]
> > Sent: Wednesday, November 5, 2014 11:04 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
> >
> > +1 to what you’ve both stated.
> >
> > Cordova-browser shouldn't be responsible for providing mock data,
> > UI, or any additional functionality for simulating a plug-in. It’s
> > primary goal
> is
> > to (as you both mention) be responsible for getting apps to run in
> > the browser. Simulating plug-in behavior would be external to that
> > in some
> form
> > or fashion.
> >
> > Cheers,
> > Kirupa
> >
> > -----Original Message-----
> > From: mikeywbrooks@gmail.com [mailto:mikeywbrooks@gmail.com] On
> > Behalf
> Of
> > Michael Brooks
> > Sent: Wednesday, November 5, 2014 9:22 AM
> > To: dev@cordova.apache.org
> > Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
> >
> > >
> > > In my view, ripple should be built on top of the browser platform
> > > work, and ideally also decouple the UI from the plugin
> > > instrumentation, but thats up to the folks running that effort.
> >
> >
> >
> >
> > > With all this in mind, I think the cordova-browser effort should
> > > proceed with current direction, but keep in mind that more
> > > advanced plugin instrumentation doesn't belong there.
> >
> >
> > This echo's my views on the Browser Platform and Ripple as well.
> >
> > Ideally, the Browser Platform is a production deployment environment
> > for the web, while Ripple is debugging instrumentation that runs on
> > the
> Browser
> > Platform.
> >
> > On Wed, Nov 5, 2014 at 8:04 AM, Michal Mocny <mm...@google.com> wrote:
> >
> > > We debated a bit about browser vs ripple at phonegap day
> > > (especially Intel folks who have done lots of work here), and the
> > > my personal tldr; is that there is in fact a home for both.
> > >
> > > Basically, browser-platform is for getting apps running in a
> > > browser
> > > (duh) with as much working functionality as possible. Its
> > > supposed to simplify the 'if cordova then dialog else alert'
> > > problem, so you can build even more of your app with just local
> > > development. Seemingly this could be used to make targeting both web and app even easier.
> > >
> > > Ripple is for instrumenting/debugging apps by manipulating plugins.
> > > Its about having a UI that reaches into geolocation or camera and
> > > controls what the plugin returns to the app. Its about re-running
> > > the same device events over and over for tracking application
> > > logic
> changes.
> > >
> > > Some of the work ripple has done traditionally can now in fact
> > > just be done via browser DevTools, but their are still some cases
> > > where custom hooks into plugins are the best way to provide a good
> > > local "simulator". (Chrome DevTools at least now provide mobile
> > > emulation,
> > unsure about others).
> > >
> > > In my view, ripple should be built on top of the browser platform
> > > work, and ideally also decouple the UI from the plugin
> > > instrumentation, but thats up to the folks running that effort.
> > >
> > > With all this in mind, I think the cordova-browser effort should
> > > proceed with current direction, but keep in mind that more
> > > advanced plugin instrumentation doesn't belong there.
> > >
> > > -Michal
> > >
> >
>
Re: Summarizing thoughts on cordova-browser vs Ripple
Posted by Andrew Grieve <ag...@chromium.org>.
>From reading this, seems like it could work well to have plugins provide
both browser and ripple implementations. They could make them the same, or
have the ripple one provide some sort of nice emulation UI. e.g.
var div = ... createUI;
ripple.registerPluginUi(div)
Still also seems powerful though, to have Ripple be able to add UI for
plugins that don't provide their own.
On Mon, Nov 10, 2014 at 3:48 PM, Michal Mocny <mm...@chromium.org> wrote:
> On Thu, Nov 6, 2014 at 6:52 PM, Horn, Julian C <ju...@intel.com>
> wrote:
>
> > I'd like to introduce myself and put in my two cents here. My name is
> > Julian Horn. I work for Intel on the XDK, an integrated development
> > environment for cross-platform HTML5 applications. I am the team lead
> for
> > the Device Emulator component, which is our Ripple derivative. My
> > background is mostly in software development tools: compilers, debuggers,
> > simulators and analysis tools. I have been working with the Ripple code
> > base for a couple of years now.
> >
> > If I'm understanding the cordova-browser concept, the implementation of a
> > Cordova API for the browser platform should consist of code that bridges
> > between the platform-independent Cordova API and whatever equivalent is
> > available in the current browser session. For example, the camera API
> > getPicture function would invoke the getUserMedia API, which is the
> closest
> > thing we have to a W3C standard way to take a picture. If the browser
> > doesn't implement this API or the host system doesn't have a camera, then
> > the getPicture call fails with "camera unavailable".
> >
> > This seems like a fine way to gradually migrate from packaged apps that
> > rely on native code plugins to pure web apps that rely on the browser to
> > access mobile device resources. This should work great when you have a
> > browser-portable implementation. It may be a challenge with some
> plugins,
> > since of course Cordova/PhoneGap was designed to cover gaps in browser
> > support. But at least we don't have to wait for a real W3C standard to
> be
> > agreed.
> >
> > The goal of our XDK product is to facilitate development of
> cross-platform
> > mobile HTML5 applications. We see the Device Emulator (our Ripple) as
> > enabling developers to test an HTML5 mobile application on the host
> > system. While this is no substitute for testing on real hardware, the
> > Device Emulator does offers some advantages that can accelerate the
> > development process. To summarize quickly:
> > * It’s really fast.
> > * You don't need an array of mobile devices.
> > * You can put off dealing with weird target system quirks until after
> you
> > get your basic application logic debugged.
> > * You get full native JavaScript debugging, which is faster, simpler,
> and
> > more available than remote debug.
> > * You can create testing situations that are difficult or impossible to
> > create in real life, such as GPS timeout.
> > * It's a great teaching tool.
> > * It allows you to prototype quickly.
> >
> > Assuming the functionality delivered by Ripple has value (and we find it
> > does), one needs a way to reconcile this with the cordova-browser effort.
> > Here's how I see that working out.
> >
> > One idea is to rely on the browser developer tools to supply emulation
> > support and just drop Ripple. I don't like this much. Today the
> developer
> > tools emulation UI is fairly primitive, but of course, there is nothing
> > stopping the browser vendors from building all the functionality in the
> > Ripple Geolocation panel (or indeed all of Ripple) into the developer
> > tools. The bigger problem from my point of view is that this is a closed
> > system. There's no way for a non-browser-vendor to extend the browser to
> > provide emulation support for new plugin APIs.
> >
> > The alternative is to do a "cordova prepare browser" and load the results
> > into Ripple.
>
>
> This would be my preference if at all possible. Specifically, I think
> ripple would move much faster and be better architected if it didn't have
> to depend on making changes directly to cordova. Though it should be
> acceptable to create a ripple platform (cordova run ripple) if really need
> be.
>
>
> > Assuming the browser platform code follows the usual pattern, that is,
> > that it goes through an exec/execProxy layer, it should be possible for
> > Ripple to intercept at that level. Ripple can delegate to the execProxy
> > implementation if it has no emulation-time implementation of its own.
> This
> > means that unrecognized APIs run unaltered, in which case you get
> whatever
> > behavior you get on the browser platform. This is a really exciting
> > prospect. It's way better than that "we don't know what to do" dialog
> that
> > Ripple puts up when an exec layer function it doesn't recognize is
> called.
> >
>
> Thats interesting. I hadn't considered doing it this way, but it actually
> sounds like a great solution.
>
>
> >
> > In fact there are some Cordova APIs that Ripple implements by mostly
> > delegating to a Chrome-specific API. For example, the simulation of the
> > Cordova File API is based on webkitRequestFileSystem. (Unfortunately no
> > other browser vendors have seen fit to support this API.) In those
> cases I
> > think the Ripple implementation of the API is likely to coincide nicely
> > with the browser platform implementation.
> >
> > Unlike ripple-as-a-platform, this model doesn't allow plugin authors to
> > provide their own emulation-time solutions. I was always skeptical that
> > many plugin authors would really do this (others disagree). But if they
> at
> > least provide a browser implementation then Ripple has something to fall
> > back on. And if there's something better that can be done, we can always
> > extend Ripple.
> >
>
> Given that the biggest benefit of Ripple is to provide UI to dig into and
> manually adjust the plugin behaviour, I share your sentiment. I did voice
> that I thought plugin authors would provide implementations -- but that is
> for what we know are classifying as cordova-browser implementations (even
> if just stubs / no-ops).
>
>
> >
> > Julian
> >
> > -----Original Message-----
> > From: Parashuram Narasimhan (MS OPEN TECH) [mailto:
> panarasi@microsoft.com]
> > Sent: Wednesday, November 05, 2014 2:25 PM
> > To: dev@cordova.apache.org
> > Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
> >
> > MSOpenTech is currently working on porting our ripple-platform prototype
> -
> > https://github.com/MSOpenTech/cordova-ripple to work on top of
> > cordova-browser. The question on how each plugin exposes a UI to provide
> > mock data is still up for discussion, but Intel has a lot of context on
> > that area.
> >
> > -----Original Message-----
> > From: Kirupa Chinnathambi [mailto:kirupac@microsoft.com]
> > Sent: Wednesday, November 5, 2014 11:04 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
> >
> > +1 to what you’ve both stated.
> >
> > Cordova-browser shouldn't be responsible for providing mock data, UI, or
> > any additional functionality for simulating a plug-in. It’s primary goal
> is
> > to (as you both mention) be responsible for getting apps to run in the
> > browser. Simulating plug-in behavior would be external to that in some
> form
> > or fashion.
> >
> > Cheers,
> > Kirupa
> >
> > -----Original Message-----
> > From: mikeywbrooks@gmail.com [mailto:mikeywbrooks@gmail.com] On Behalf
> Of
> > Michael Brooks
> > Sent: Wednesday, November 5, 2014 9:22 AM
> > To: dev@cordova.apache.org
> > Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
> >
> > >
> > > In my view, ripple should be built on top of the browser platform
> > > work, and ideally also decouple the UI from the plugin
> > > instrumentation, but thats up to the folks running that effort.
> >
> >
> >
> >
> > > With all this in mind, I think the cordova-browser effort should
> > > proceed with current direction, but keep in mind that more advanced
> > > plugin instrumentation doesn't belong there.
> >
> >
> > This echo's my views on the Browser Platform and Ripple as well.
> >
> > Ideally, the Browser Platform is a production deployment environment for
> > the web, while Ripple is debugging instrumentation that runs on the
> Browser
> > Platform.
> >
> > On Wed, Nov 5, 2014 at 8:04 AM, Michal Mocny <mm...@google.com> wrote:
> >
> > > We debated a bit about browser vs ripple at phonegap day (especially
> > > Intel folks who have done lots of work here), and the my personal
> > > tldr; is that there is in fact a home for both.
> > >
> > > Basically, browser-platform is for getting apps running in a browser
> > > (duh) with as much working functionality as possible. Its supposed to
> > > simplify the 'if cordova then dialog else alert' problem, so you can
> > > build even more of your app with just local development. Seemingly
> > > this could be used to make targeting both web and app even easier.
> > >
> > > Ripple is for instrumenting/debugging apps by manipulating plugins.
> > > Its about having a UI that reaches into geolocation or camera and
> > > controls what the plugin returns to the app. Its about re-running the
> > > same device events over and over for tracking application logic
> changes.
> > >
> > > Some of the work ripple has done traditionally can now in fact just be
> > > done via browser DevTools, but their are still some cases where custom
> > > hooks into plugins are the best way to provide a good local
> > > "simulator". (Chrome DevTools at least now provide mobile emulation,
> > unsure about others).
> > >
> > > In my view, ripple should be built on top of the browser platform
> > > work, and ideally also decouple the UI from the plugin
> > > instrumentation, but thats up to the folks running that effort.
> > >
> > > With all this in mind, I think the cordova-browser effort should
> > > proceed with current direction, but keep in mind that more advanced
> > > plugin instrumentation doesn't belong there.
> > >
> > > -Michal
> > >
> >
>
Re: Summarizing thoughts on cordova-browser vs Ripple
Posted by Michal Mocny <mm...@chromium.org>.
On Thu, Nov 6, 2014 at 6:52 PM, Horn, Julian C <ju...@intel.com>
wrote:
> I'd like to introduce myself and put in my two cents here. My name is
> Julian Horn. I work for Intel on the XDK, an integrated development
> environment for cross-platform HTML5 applications. I am the team lead for
> the Device Emulator component, which is our Ripple derivative. My
> background is mostly in software development tools: compilers, debuggers,
> simulators and analysis tools. I have been working with the Ripple code
> base for a couple of years now.
>
> If I'm understanding the cordova-browser concept, the implementation of a
> Cordova API for the browser platform should consist of code that bridges
> between the platform-independent Cordova API and whatever equivalent is
> available in the current browser session. For example, the camera API
> getPicture function would invoke the getUserMedia API, which is the closest
> thing we have to a W3C standard way to take a picture. If the browser
> doesn't implement this API or the host system doesn't have a camera, then
> the getPicture call fails with "camera unavailable".
>
> This seems like a fine way to gradually migrate from packaged apps that
> rely on native code plugins to pure web apps that rely on the browser to
> access mobile device resources. This should work great when you have a
> browser-portable implementation. It may be a challenge with some plugins,
> since of course Cordova/PhoneGap was designed to cover gaps in browser
> support. But at least we don't have to wait for a real W3C standard to be
> agreed.
>
> The goal of our XDK product is to facilitate development of cross-platform
> mobile HTML5 applications. We see the Device Emulator (our Ripple) as
> enabling developers to test an HTML5 mobile application on the host
> system. While this is no substitute for testing on real hardware, the
> Device Emulator does offers some advantages that can accelerate the
> development process. To summarize quickly:
> * It’s really fast.
> * You don't need an array of mobile devices.
> * You can put off dealing with weird target system quirks until after you
> get your basic application logic debugged.
> * You get full native JavaScript debugging, which is faster, simpler, and
> more available than remote debug.
> * You can create testing situations that are difficult or impossible to
> create in real life, such as GPS timeout.
> * It's a great teaching tool.
> * It allows you to prototype quickly.
>
> Assuming the functionality delivered by Ripple has value (and we find it
> does), one needs a way to reconcile this with the cordova-browser effort.
> Here's how I see that working out.
>
> One idea is to rely on the browser developer tools to supply emulation
> support and just drop Ripple. I don't like this much. Today the developer
> tools emulation UI is fairly primitive, but of course, there is nothing
> stopping the browser vendors from building all the functionality in the
> Ripple Geolocation panel (or indeed all of Ripple) into the developer
> tools. The bigger problem from my point of view is that this is a closed
> system. There's no way for a non-browser-vendor to extend the browser to
> provide emulation support for new plugin APIs.
>
> The alternative is to do a "cordova prepare browser" and load the results
> into Ripple.
This would be my preference if at all possible. Specifically, I think
ripple would move much faster and be better architected if it didn't have
to depend on making changes directly to cordova. Though it should be
acceptable to create a ripple platform (cordova run ripple) if really need
be.
> Assuming the browser platform code follows the usual pattern, that is,
> that it goes through an exec/execProxy layer, it should be possible for
> Ripple to intercept at that level. Ripple can delegate to the execProxy
> implementation if it has no emulation-time implementation of its own. This
> means that unrecognized APIs run unaltered, in which case you get whatever
> behavior you get on the browser platform. This is a really exciting
> prospect. It's way better than that "we don't know what to do" dialog that
> Ripple puts up when an exec layer function it doesn't recognize is called.
>
Thats interesting. I hadn't considered doing it this way, but it actually
sounds like a great solution.
>
> In fact there are some Cordova APIs that Ripple implements by mostly
> delegating to a Chrome-specific API. For example, the simulation of the
> Cordova File API is based on webkitRequestFileSystem. (Unfortunately no
> other browser vendors have seen fit to support this API.) In those cases I
> think the Ripple implementation of the API is likely to coincide nicely
> with the browser platform implementation.
>
> Unlike ripple-as-a-platform, this model doesn't allow plugin authors to
> provide their own emulation-time solutions. I was always skeptical that
> many plugin authors would really do this (others disagree). But if they at
> least provide a browser implementation then Ripple has something to fall
> back on. And if there's something better that can be done, we can always
> extend Ripple.
>
Given that the biggest benefit of Ripple is to provide UI to dig into and
manually adjust the plugin behaviour, I share your sentiment. I did voice
that I thought plugin authors would provide implementations -- but that is
for what we know are classifying as cordova-browser implementations (even
if just stubs / no-ops).
>
> Julian
>
> -----Original Message-----
> From: Parashuram Narasimhan (MS OPEN TECH) [mailto:panarasi@microsoft.com]
> Sent: Wednesday, November 05, 2014 2:25 PM
> To: dev@cordova.apache.org
> Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
>
> MSOpenTech is currently working on porting our ripple-platform prototype -
> https://github.com/MSOpenTech/cordova-ripple to work on top of
> cordova-browser. The question on how each plugin exposes a UI to provide
> mock data is still up for discussion, but Intel has a lot of context on
> that area.
>
> -----Original Message-----
> From: Kirupa Chinnathambi [mailto:kirupac@microsoft.com]
> Sent: Wednesday, November 5, 2014 11:04 AM
> To: dev@cordova.apache.org
> Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
>
> +1 to what you’ve both stated.
>
> Cordova-browser shouldn't be responsible for providing mock data, UI, or
> any additional functionality for simulating a plug-in. It’s primary goal is
> to (as you both mention) be responsible for getting apps to run in the
> browser. Simulating plug-in behavior would be external to that in some form
> or fashion.
>
> Cheers,
> Kirupa
>
> -----Original Message-----
> From: mikeywbrooks@gmail.com [mailto:mikeywbrooks@gmail.com] On Behalf Of
> Michael Brooks
> Sent: Wednesday, November 5, 2014 9:22 AM
> To: dev@cordova.apache.org
> Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
>
> >
> > In my view, ripple should be built on top of the browser platform
> > work, and ideally also decouple the UI from the plugin
> > instrumentation, but thats up to the folks running that effort.
>
>
>
>
> > With all this in mind, I think the cordova-browser effort should
> > proceed with current direction, but keep in mind that more advanced
> > plugin instrumentation doesn't belong there.
>
>
> This echo's my views on the Browser Platform and Ripple as well.
>
> Ideally, the Browser Platform is a production deployment environment for
> the web, while Ripple is debugging instrumentation that runs on the Browser
> Platform.
>
> On Wed, Nov 5, 2014 at 8:04 AM, Michal Mocny <mm...@google.com> wrote:
>
> > We debated a bit about browser vs ripple at phonegap day (especially
> > Intel folks who have done lots of work here), and the my personal
> > tldr; is that there is in fact a home for both.
> >
> > Basically, browser-platform is for getting apps running in a browser
> > (duh) with as much working functionality as possible. Its supposed to
> > simplify the 'if cordova then dialog else alert' problem, so you can
> > build even more of your app with just local development. Seemingly
> > this could be used to make targeting both web and app even easier.
> >
> > Ripple is for instrumenting/debugging apps by manipulating plugins.
> > Its about having a UI that reaches into geolocation or camera and
> > controls what the plugin returns to the app. Its about re-running the
> > same device events over and over for tracking application logic changes.
> >
> > Some of the work ripple has done traditionally can now in fact just be
> > done via browser DevTools, but their are still some cases where custom
> > hooks into plugins are the best way to provide a good local
> > "simulator". (Chrome DevTools at least now provide mobile emulation,
> unsure about others).
> >
> > In my view, ripple should be built on top of the browser platform
> > work, and ideally also decouple the UI from the plugin
> > instrumentation, but thats up to the folks running that effort.
> >
> > With all this in mind, I think the cordova-browser effort should
> > proceed with current direction, but keep in mind that more advanced
> > plugin instrumentation doesn't belong there.
> >
> > -Michal
> >
>
RE: Summarizing thoughts on cordova-browser vs Ripple
Posted by "Horn, Julian C" <ju...@intel.com>.
I'd like to introduce myself and put in my two cents here. My name is Julian Horn. I work for Intel on the XDK, an integrated development environment for cross-platform HTML5 applications. I am the team lead for the Device Emulator component, which is our Ripple derivative. My background is mostly in software development tools: compilers, debuggers, simulators and analysis tools. I have been working with the Ripple code base for a couple of years now.
If I'm understanding the cordova-browser concept, the implementation of a Cordova API for the browser platform should consist of code that bridges between the platform-independent Cordova API and whatever equivalent is available in the current browser session. For example, the camera API getPicture function would invoke the getUserMedia API, which is the closest thing we have to a W3C standard way to take a picture. If the browser doesn't implement this API or the host system doesn't have a camera, then the getPicture call fails with "camera unavailable".
This seems like a fine way to gradually migrate from packaged apps that rely on native code plugins to pure web apps that rely on the browser to access mobile device resources. This should work great when you have a browser-portable implementation. It may be a challenge with some plugins, since of course Cordova/PhoneGap was designed to cover gaps in browser support. But at least we don't have to wait for a real W3C standard to be agreed.
The goal of our XDK product is to facilitate development of cross-platform mobile HTML5 applications. We see the Device Emulator (our Ripple) as enabling developers to test an HTML5 mobile application on the host system. While this is no substitute for testing on real hardware, the Device Emulator does offers some advantages that can accelerate the development process. To summarize quickly:
* It’s really fast.
* You don't need an array of mobile devices.
* You can put off dealing with weird target system quirks until after you get your basic application logic debugged.
* You get full native JavaScript debugging, which is faster, simpler, and more available than remote debug.
* You can create testing situations that are difficult or impossible to create in real life, such as GPS timeout.
* It's a great teaching tool.
* It allows you to prototype quickly.
Assuming the functionality delivered by Ripple has value (and we find it does), one needs a way to reconcile this with the cordova-browser effort. Here's how I see that working out.
One idea is to rely on the browser developer tools to supply emulation support and just drop Ripple. I don't like this much. Today the developer tools emulation UI is fairly primitive, but of course, there is nothing stopping the browser vendors from building all the functionality in the Ripple Geolocation panel (or indeed all of Ripple) into the developer tools. The bigger problem from my point of view is that this is a closed system. There's no way for a non-browser-vendor to extend the browser to provide emulation support for new plugin APIs.
The alternative is to do a "cordova prepare browser" and load the results into Ripple. Assuming the browser platform code follows the usual pattern, that is, that it goes through an exec/execProxy layer, it should be possible for Ripple to intercept at that level. Ripple can delegate to the execProxy implementation if it has no emulation-time implementation of its own. This means that unrecognized APIs run unaltered, in which case you get whatever behavior you get on the browser platform. This is a really exciting prospect. It's way better than that "we don't know what to do" dialog that Ripple puts up when an exec layer function it doesn't recognize is called.
In fact there are some Cordova APIs that Ripple implements by mostly delegating to a Chrome-specific API. For example, the simulation of the Cordova File API is based on webkitRequestFileSystem. (Unfortunately no other browser vendors have seen fit to support this API.) In those cases I think the Ripple implementation of the API is likely to coincide nicely with the browser platform implementation.
Unlike ripple-as-a-platform, this model doesn't allow plugin authors to provide their own emulation-time solutions. I was always skeptical that many plugin authors would really do this (others disagree). But if they at least provide a browser implementation then Ripple has something to fall back on. And if there's something better that can be done, we can always extend Ripple.
Julian
-----Original Message-----
From: Parashuram Narasimhan (MS OPEN TECH) [mailto:panarasi@microsoft.com]
Sent: Wednesday, November 05, 2014 2:25 PM
To: dev@cordova.apache.org
Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
MSOpenTech is currently working on porting our ripple-platform prototype - https://github.com/MSOpenTech/cordova-ripple to work on top of cordova-browser. The question on how each plugin exposes a UI to provide mock data is still up for discussion, but Intel has a lot of context on that area.
-----Original Message-----
From: Kirupa Chinnathambi [mailto:kirupac@microsoft.com]
Sent: Wednesday, November 5, 2014 11:04 AM
To: dev@cordova.apache.org
Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
+1 to what you’ve both stated.
Cordova-browser shouldn't be responsible for providing mock data, UI, or any additional functionality for simulating a plug-in. It’s primary goal is to (as you both mention) be responsible for getting apps to run in the browser. Simulating plug-in behavior would be external to that in some form or fashion.
Cheers,
Kirupa
-----Original Message-----
From: mikeywbrooks@gmail.com [mailto:mikeywbrooks@gmail.com] On Behalf Of Michael Brooks
Sent: Wednesday, November 5, 2014 9:22 AM
To: dev@cordova.apache.org
Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
>
> In my view, ripple should be built on top of the browser platform
> work, and ideally also decouple the UI from the plugin
> instrumentation, but thats up to the folks running that effort.
> With all this in mind, I think the cordova-browser effort should
> proceed with current direction, but keep in mind that more advanced
> plugin instrumentation doesn't belong there.
This echo's my views on the Browser Platform and Ripple as well.
Ideally, the Browser Platform is a production deployment environment for the web, while Ripple is debugging instrumentation that runs on the Browser Platform.
On Wed, Nov 5, 2014 at 8:04 AM, Michal Mocny <mm...@google.com> wrote:
> We debated a bit about browser vs ripple at phonegap day (especially
> Intel folks who have done lots of work here), and the my personal
> tldr; is that there is in fact a home for both.
>
> Basically, browser-platform is for getting apps running in a browser
> (duh) with as much working functionality as possible. Its supposed to
> simplify the 'if cordova then dialog else alert' problem, so you can
> build even more of your app with just local development. Seemingly
> this could be used to make targeting both web and app even easier.
>
> Ripple is for instrumenting/debugging apps by manipulating plugins.
> Its about having a UI that reaches into geolocation or camera and
> controls what the plugin returns to the app. Its about re-running the
> same device events over and over for tracking application logic changes.
>
> Some of the work ripple has done traditionally can now in fact just be
> done via browser DevTools, but their are still some cases where custom
> hooks into plugins are the best way to provide a good local
> "simulator". (Chrome DevTools at least now provide mobile emulation, unsure about others).
>
> In my view, ripple should be built on top of the browser platform
> work, and ideally also decouple the UI from the plugin
> instrumentation, but thats up to the folks running that effort.
>
> With all this in mind, I think the cordova-browser effort should
> proceed with current direction, but keep in mind that more advanced
> plugin instrumentation doesn't belong there.
>
> -Michal
>
RE: Summarizing thoughts on cordova-browser vs Ripple
Posted by "Parashuram Narasimhan (MS OPEN TECH)" <pa...@microsoft.com>.
MSOpenTech is currently working on porting our ripple-platform prototype - https://github.com/MSOpenTech/cordova-ripple to work on top of cordova-browser. The question on how each plugin exposes a UI to provide mock data is still up for discussion, but Intel has a lot of context on that area.
-----Original Message-----
From: Kirupa Chinnathambi [mailto:kirupac@microsoft.com]
Sent: Wednesday, November 5, 2014 11:04 AM
To: dev@cordova.apache.org
Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
+1 to what you’ve both stated.
Cordova-browser shouldn't be responsible for providing mock data, UI, or any additional functionality for simulating a plug-in. It’s primary goal is to (as you both mention) be responsible for getting apps to run in the browser. Simulating plug-in behavior would be external to that in some form or fashion.
Cheers,
Kirupa
-----Original Message-----
From: mikeywbrooks@gmail.com [mailto:mikeywbrooks@gmail.com] On Behalf Of Michael Brooks
Sent: Wednesday, November 5, 2014 9:22 AM
To: dev@cordova.apache.org
Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
>
> In my view, ripple should be built on top of the browser platform
> work, and ideally also decouple the UI from the plugin
> instrumentation, but thats up to the folks running that effort.
> With all this in mind, I think the cordova-browser effort should
> proceed with current direction, but keep in mind that more advanced
> plugin instrumentation doesn't belong there.
This echo's my views on the Browser Platform and Ripple as well.
Ideally, the Browser Platform is a production deployment environment for the web, while Ripple is debugging instrumentation that runs on the Browser Platform.
On Wed, Nov 5, 2014 at 8:04 AM, Michal Mocny <mm...@google.com> wrote:
> We debated a bit about browser vs ripple at phonegap day (especially
> Intel folks who have done lots of work here), and the my personal
> tldr; is that there is in fact a home for both.
>
> Basically, browser-platform is for getting apps running in a browser
> (duh) with as much working functionality as possible. Its supposed to
> simplify the 'if cordova then dialog else alert' problem, so you can
> build even more of your app with just local development. Seemingly
> this could be used to make targeting both web and app even easier.
>
> Ripple is for instrumenting/debugging apps by manipulating plugins.
> Its about having a UI that reaches into geolocation or camera and
> controls what the plugin returns to the app. Its about re-running the
> same device events over and over for tracking application logic changes.
>
> Some of the work ripple has done traditionally can now in fact just be
> done via browser DevTools, but their are still some cases where custom
> hooks into plugins are the best way to provide a good local
> "simulator". (Chrome DevTools at least now provide mobile emulation, unsure about others).
>
> In my view, ripple should be built on top of the browser platform
> work, and ideally also decouple the UI from the plugin
> instrumentation, but thats up to the folks running that effort.
>
> With all this in mind, I think the cordova-browser effort should
> proceed with current direction, but keep in mind that more advanced
> plugin instrumentation doesn't belong there.
>
> -Michal
>
RE: Summarizing thoughts on cordova-browser vs Ripple
Posted by Kirupa Chinnathambi <ki...@microsoft.com>.
+1 to what you’ve both stated.
Cordova-browser shouldn't be responsible for providing mock data, UI, or any additional functionality for simulating a plug-in. It’s primary goal is to (as you both mention) be responsible for getting apps to run in the browser. Simulating plug-in behavior would be external to that in some form or fashion.
Cheers,
Kirupa
-----Original Message-----
From: mikeywbrooks@gmail.com [mailto:mikeywbrooks@gmail.com] On Behalf Of Michael Brooks
Sent: Wednesday, November 5, 2014 9:22 AM
To: dev@cordova.apache.org
Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
>
> In my view, ripple should be built on top of the browser platform
> work, and ideally also decouple the UI from the plugin
> instrumentation, but thats up to the folks running that effort.
> With all this in mind, I think the cordova-browser effort should
> proceed with current direction, but keep in mind that more advanced
> plugin instrumentation doesn't belong there.
This echo's my views on the Browser Platform and Ripple as well.
Ideally, the Browser Platform is a production deployment environment for the web, while Ripple is debugging instrumentation that runs on the Browser Platform.
On Wed, Nov 5, 2014 at 8:04 AM, Michal Mocny <mm...@google.com> wrote:
> We debated a bit about browser vs ripple at phonegap day (especially
> Intel folks who have done lots of work here), and the my personal
> tldr; is that there is in fact a home for both.
>
> Basically, browser-platform is for getting apps running in a browser
> (duh) with as much working functionality as possible. Its supposed to
> simplify the 'if cordova then dialog else alert' problem, so you can
> build even more of your app with just local development. Seemingly
> this could be used to make targeting both web and app even easier.
>
> Ripple is for instrumenting/debugging apps by manipulating plugins.
> Its about having a UI that reaches into geolocation or camera and
> controls what the plugin returns to the app. Its about re-running the
> same device events over and over for tracking application logic changes.
>
> Some of the work ripple has done traditionally can now in fact just be
> done via browser DevTools, but their are still some cases where custom
> hooks into plugins are the best way to provide a good local
> "simulator". (Chrome DevTools at least now provide mobile emulation, unsure about others).
>
> In my view, ripple should be built on top of the browser platform
> work, and ideally also decouple the UI from the plugin
> instrumentation, but thats up to the folks running that effort.
>
> With all this in mind, I think the cordova-browser effort should
> proceed with current direction, but keep in mind that more advanced
> plugin instrumentation doesn't belong there.
>
> -Michal
>
Re: Summarizing thoughts on cordova-browser vs Ripple
Posted by Michael Brooks <mi...@michaelbrooks.ca>.
>
> In my view, ripple should be built on top of the browser platform work, and
> ideally also decouple the UI from the plugin instrumentation, but thats up
> to the folks running that effort.
> With all this in mind, I think the cordova-browser effort should proceed
> with current direction, but keep in mind that more advanced plugin
> instrumentation doesn't belong there.
This echo's my views on the Browser Platform and Ripple as well.
Ideally, the Browser Platform is a production deployment environment for
the web, while Ripple is debugging instrumentation that runs on the Browser
Platform.
On Wed, Nov 5, 2014 at 8:04 AM, Michal Mocny <mm...@google.com> wrote:
> We debated a bit about browser vs ripple at phonegap day (especially Intel
> folks who have done lots of work here), and the my personal tldr; is that
> there is in fact a home for both.
>
> Basically, browser-platform is for getting apps running in a browser (duh)
> with as much working functionality as possible. Its supposed to simplify
> the 'if cordova then dialog else alert' problem, so you can build even more
> of your app with just local development. Seemingly this could be used to
> make targeting both web and app even easier.
>
> Ripple is for instrumenting/debugging apps by manipulating plugins. Its
> about having a UI that reaches into geolocation or camera and controls what
> the plugin returns to the app. Its about re-running the same device events
> over and over for tracking application logic changes.
>
> Some of the work ripple has done traditionally can now in fact just be done
> via browser DevTools, but their are still some cases where custom hooks
> into plugins are the best way to provide a good local "simulator". (Chrome
> DevTools at least now provide mobile emulation, unsure about others).
>
> In my view, ripple should be built on top of the browser platform work, and
> ideally also decouple the UI from the plugin instrumentation, but thats up
> to the folks running that effort.
>
> With all this in mind, I think the cordova-browser effort should proceed
> with current direction, but keep in mind that more advanced plugin
> instrumentation doesn't belong there.
>
> -Michal
>