Hi Mikhail and Alex, "Decouple Chromium content API integration and xwalk runtime logic classes", I think now I understand and agree with this point :-) The plan is that the main classes in Crosswalk are classes of our own, instead of piggingback in objects like the clients, that do exist (possibly with the lifetime we desire) but are more structured to serve Chromium Content API.
Assuming the above interpretation is correct, LGTM with the comments below. - The proposal is missing the targetted Crosswalk release. - The proposal is missing the "planned steps". Even if it's a draft plan, it would be helpful for me, and possibly for others. - CmdLineStrategy: it seems the goal here is to decouple any action specific of Crosswalk from the ContentBrowserClient code. Wouldn't suffice for the beginning to simply call ApplicationSystem with the command line to handle? If needed later we can add strategy logic there. - I still fail to see the need for ApplicationPageDisplayStrategy, could you elaborate more? Is it just a detail of implementation of XWalkApplication or is it needed by the design? If it's an detail I suggest postponing this. - Is there any dependency between this work and the work being done inside ApplicationStore? I'm assuming no, but it's nice to have it cleared. - Who will own ApplicationData or will it remain a refcounted object? Congrats, I'm confident that these changes will achieve the intended goals. Cheers, Caio _______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
