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.
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.
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.
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
