> -----Original Message----- > From: Crosswalk-dev [mailto:crosswalk-dev-bounces@lists.crosswalk- > project.org] On Behalf Of Pozdnyakov, Mikhail > Sent: Friday, November 22, 2013 10:41 PM > To: crosswalk-dev@lists.crosswalk-project.org > Subject: [Crosswalk-dev] Proposal for design improvements in XWalk > runtime > > Hi, > > Here I would like to propose briefly a plan of XWalk runtime refactoring/re- > design. This is not an "intend-to-implement" message so far but it is rather a > heads-up and an invitation for a discussion. > > The rationals (dude, what's the problem with the current design? > everything works perfect already! ): > > - The current design does not allow shared process model architecture on > runtime side, meaning that all the runtime(!) will be screwed up if more > than one application runs. > Almost all 'runtime' classes (except event manager :) ) are expected to > work only with a single application. > - Name of classes is totaly misleading making it hard to comprehend what's > going on ("Runtime" which is not actually a runtime, "RuntimeContext" > which is not actually a runtime context and so on). > - The functionality of classes is not clear making it hard to introduce new > features. > - Object's lifecycle and ownership is not clear (should I bring examples to > prove it?) > > If you disagree with the last three rationals please try to answer at least > these following questions (so natural for a web runtime design) in terms of > XWalk classes: > Which object is representing a running application (don't say "Application" > class! because "Application" class is representing application meta-data :) )? > Who manages the running applications and controls their life-cycle? > Which object represents an application's web page? > Which object shows the application web page (decides how/where to show > it)? > > High level design changes (by me & Alex Shalamov) > > Main intentions: > - provide functionality that would allow to run several applications at the > same time > - decouple chromium adaptation and xwalk runtime logic > - make it easier to comprehend the code > > List of changes: > > XWalkContentBrowserClient: > - Not a singleton anymore > - Will accept XWalkCmdLineStrategy object - a delegate(strategy) object for > handling the cmd line arguments. > > XWalkCmdLineStrategy (maybe there is a better name): > - A strategy class encapsulating cmd line parsing and showing a browser > window or invoking an app (depending on cmd line parameters) > - Owned by XWalkContentBrowserClient > - XWalkCmdLineStrategy will encapsulate the logic currently present at > ApplicationSystem's HandleApplicationManagementCommands() and > LaunchFromCommandLine() methods and also at > part of XWalkBrowserMainParts::PreMainMessageLoopRun() logic. [Ming, Bai] Do we still need to support command line options for each application/browser launching? I think after the shared runtime process mode is ready, we need to remove the simple browser mode, and merge the functionality to xwalk-launcher, like xwalk-launcher --launch="http://ffda"; or anything like that. The command line parsing will only happen once, when the daemon starts up.
> > XWalkBrowserContext: > - The present RuntimeContext should be renamed to XWalkBrowserContext > - XWalkBrowserContext should not own any appliction classes > - XWalkBrowserContext is created by main parts and passed to an > XWalkApplicationManager object > > XWalkApplicationManager: > - a new singleton class ( its instance is created by mainparts but there is > global function to access the instance from outside) > - Application manager is responsible for launching applications, managing > the running applications, installation/uninstallation of applications, > providing application services > - XWalkApplicationManager will substitute the present ApplicationSystem > and ApplicationService classes > - XWalkApplicationManager will own ApplicationStorage and > ApplicationEventManager > > XWalkApplicationMetaData: > - The present Application class will be renamed to ApplicationMetaData. > > XWalkApplication: > - A new class representing an application > - XWalkApplication class will encapsulate functionalty of present > ApplicationProcessManager, RuntimeRegistry and (partially) Runtime > classes > - XWalkApplication will be owned be ApplicationManager > - XWalkApplication will contain ApplicationMetaData data member > - XWalkApplication will contain list of XWalkApplicationPages. [Ming, Bai] Does the XWalkApplication class represents a static application abstraction, or a running application instance? > > XWalkApplicationPage: > - A new class representing a web page (There's one-to-one correspondence > between WebContents and > XWalkApplicationPage). > - XWalkApplicationPage will encapsulate most of the logic currently present > in Runtime class > - XWalkApplicationPage will be owned by the corresponding > XWalkApplication instance. > > XWalkApplicationPageDisplayStrategy (better name here is also possible :) ) > - A new strategy class encapsulating the logic for showing an application > page > - This class will substitute present Runtime::AttachDefaultWindow and > Runtime::AttachWindow methods. > - No restricted ownership. In principal can be allocated even on stack. > > The design doc (and class diagram) is coming. [Ming, Bai] Thanks for the help on refactoring all the classes, it's better to discuss the implementation details in somewhere like google doc rather than a ML, looking forward to that. > > Comments and questions are appreciated. > > BR, > Mikhail > --------------------------------------------------------------------- > 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 > Crosswalk-dev@lists.crosswalk-project.org > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev _______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
