Re: Summarizing thoughts on cordova-browser vs Ripple
On 11/15/14, 2:17 PM, Michal Mocny mmo...@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
On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden rayca...@adobe.com wrote: On 11/15/14, 2:17 PM, Michal Mocny mmo...@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
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 mmo...@chromium.org wrote: On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden rayca...@adobe.com wrote: On 11/15/14, 2:17 PM, Michal Mocny mmo...@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
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.ler...@gmail.com [mailto:brian.ler...@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 mmo...@chromium.org wrote: On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden rayca...@adobe.com wrote: On 11/15/14, 2:17 PM, Michal Mocny mmo...@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
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 serge.lu...@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.ler...@gmail.com [mailto:brian.ler...@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 mmo...@chromium.org wrote: On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden rayca...@adobe.com wrote: On 11/15/14, 2:17 PM, Michal Mocny mmo...@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
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 mmo...@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 serge.lu...@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.ler...@gmail.com [mailto:brian.ler...@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 mmo...@chromium.org wrote: On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden rayca...@adobe.com wrote: On 11/15/14, 2:17 PM, Michal Mocny mmo...@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
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:purplecabb...@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 mmo...@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
RE: Summarizing thoughts on cordova-browser vs Ripple
Thanks, Julian. Great summary! Best, Serge @lunarserge -Original Message- From: Horn, Julian C [mailto:julian.c.h...@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:purplecabb...@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 mmo...@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
Re: Summarizing thoughts on cordova-browser vs Ripple
On 11/15/14, 2:17 PM, Michal Mocny mmo...@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-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Summarizing thoughts on cordova-browser vs Ripple
On Mon, Nov 17, 2014 at 6:37 AM, Ray Camden rayca...@adobe.com wrote: On 11/15/14, 2:17 PM, Michal Mocny mmo...@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-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Summarizing thoughts on cordova-browser vs Ripple
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 rayca...@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
Re: Summarizing thoughts on cordova-browser vs Ripple
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: panar...@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:kiru...@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: mikeywbro...@gmail.com [mailto:mikeywbro...@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 mmo...@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
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: agri...@google.com [mailto:agri...@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 mmo...@chromium.org wrote: On Thu, Nov 6, 2014 at 6:52 PM, Horn, Julian C julian.c.h...@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
Re: Summarizing thoughts on cordova-browser vs Ripple
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 julian.c.h...@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-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Summarizing thoughts on cordova-browser vs Ripple
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:panar...@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:kiru...@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: mikeywbro...@gmail.com [mailto:mikeywbro...@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 mmo...@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
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:panar...@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
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 mmo...@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
+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: mikeywbro...@gmail.com [mailto:mikeywbro...@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 mmo...@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
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:kiru...@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: mikeywbro...@gmail.com [mailto:mikeywbro...@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 mmo...@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
Idea for simulating plugins for Cordova Browser [was: RE: Summarizing thoughts on cordova-browser vs Ripple]
+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: panar...@microsoft.com To: dev@cordova.apache.org Subject: RE: Summarizing thoughts on cordova-browser vs Ripple Date: Wed, 5 Nov 2014 19:24:44 + �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:kiru...@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: mikeywbro...@gmail.com [mailto:mikeywbro...@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 mmo...@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
