Hi Alejandro, A few things happened indeed :-) FOA we now do not support Application Events API meaning that a web app should not be notified that any other web app was un/installed or launched/terminated |=> Crosswalk does not have to be a daemon and does not have to share BP (no common context is needed). Further, app un/installation was moved from Crosswalk BP to pkgcmd (which is IMO much more natural and platform-aligned way to do). Finally we discovered that BP sharing does not give significant improvements in memory consumption.
On the other hand we've been facing with the difficulties caused by complexity of this solution (I mentioned those in the 'intent to implement'). So now (taking into account the *current* circumstances) it looks like Shared process model is an overhead and better to be simplified. I'm not an "xwalk-launcher hater", I just like when things are getting simpler and when we can afford reducing the code keeping the same functionality for the User (that's why "yay" :-) ). Again, at the time when Shared process model was introduced it had good reasons to be introduced (and the implementation was also good!) but now we've good reasons to re-consider it. Crosswalk Dbus interfaces will go away as well as xwalkctl and xwalk-launcher. BR, Mikhail ________________________________________ From: Crosswalk-dev [[email protected]] on behalf of Alejandro Piñeiro [[email protected]] Sent: Wednesday, December 10, 2014 7:41 PM To: [email protected] Subject: Re: [Crosswalk-dev] [Intent to implement] Crosswalk uses Dual process model on Tizen On 08/12/14 14:08, Pozdnyakov, Mikhail wrote: > Hi, Hi, just two questions: > > Implementation plan: > 1) Add the Tizen appcore-related logic and other functionality from > xwalk-launcher to BP > 2) Make the necessary modifications in Tizen so that it does not rely on the > Shared process model any more (e.g. launches xwalk instead of xwalk-launcher) > 3) Merge EP and GP into BP -- make it Dual process model > 4) Clean up tons of unused code, including removal of xwalk-launcher (yay!) The xwalk-launcher is somewhat recent, as was added when xwalk implemented the Run as a Service mode [1]. And it seemed that it was added because it was a advantage to run the applications as xwalk-launcher <id> instead of xwalk <id>. With this changes it seems (correct me if Im wrong), that xwalk <id> is coming back. Could you summarize what changed to make having xwalk-launcher a bad idea? (I concluded that you see xwalk-launcher as bad per se, due that yay! ;) ) Additionally, with that "run as a service" change, a basic DBUS interface was added on xwalk, to expose some services like launch/install/uninstall. xwalk-launcher is an example of an application using that DBUS interface. With this changes towards the dual process model. Is the DBUS interface going away?. Thanks [1] https://lists.crosswalk-project.org/pipermail/crosswalk-dev/2013-November/000428.html -- Alejandro Piñeiro ([email protected]) _______________________________________________ Crosswalk-dev mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ Crosswalk-dev mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
