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
