Le 05/11/2014 11:09, Tomasz Iwanek a écrit :
Hello,
I’m not sure if I’m right.
I thought Tizen common platform should be independent from any app
framework.
On current implementation every framework may install it’s own
applications which are represented by file extension and provide
installer for it.
Common should be independent from Application development tool kit such
as EFL or QT.
Common must support an HTML5 and a Native package formats, up to profile
to add more would they need it (e.g. Java).
The idea is to ease the addition of a new package formats by providing
an installer architecture which is flexible.
Are you sure that any type applications can be installed by one flow?
What will proposed generic installer cover? Crosswalk and native
framework? What native framework?
The current work is dedicated to installing App which do not affect the
platform. In short the type of App created by the SDK. Those App can be
installed in one flow.
Initially supported package format will be the one offered by the SDK
(without rpm).
Application manifests, directory structure and other are specific to
given framework.
Basicly, I always thought that this crosswalk provides integration
with tizen platform
not a tizen (common) platform provides integration with crosswalk.
Execution of an HTLM5 is a shared work. But the App live cycle is a
Tizen issue.
Secondly, many feature of web runtime requires changes in runtime part
and installer part (I think its strongly connected). That would be
pretty annoying to provides duplicated implementation of parsing some
data structures on crosswalk (to load app) and then again on generic
installer (or part of it that handles “wgt”, “xpk”). By the way, in
current crosswalk implementation, “loading app“ and “installing app“
shares common code.
Crosswalk is an application of Tizen, an important one, with privilege
but it is not the OS. Validation and enforcement of security is an OS
issue that shall be managed by the OS.
Code will be transferred /shared when possible in order to minimise
duplication but you are right that some parsing might be done twice. A
minor issue in comparison with our requirement for Security enforcement.
Those are my concerns. It’s surely implementation point of view. I’m
probably not aware about architecture decisions. Could you explain a
bit more?
Could you provides more arguments about detaching installer from
crosswalk and why this approach is better for architecture?
App live cycle is an OS responsibility. Sub contracting it to an
application force us to have two implementations with all the associated
risks when is come to guarantee the security coverage of the system.
It would also required to provide special privileges for Crosstalk to
modify the platform what is not desired as Crosswalk is very complex and
associated risk could quickly get out of control.
The drive is KISS. The AppFW is small, does one thing and we can check
that it does it well.
I hope that it clarify the point.
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
