| Summary: | JS Runtime optimization: Include only necessary runtime code | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Tony Chen <chenzhh> |
| Component: | EDT | Assignee: | Huang Ji Yong <hjiyong> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | hjiyong, jvincens, mayunf, smythew, svihovec, tww |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | RUI_Optimization | ||
| Bug Depends on: | |||
| Bug Blocks: | 367818 | ||
|
Description
Tony Chen
Set to this 0.8 milestone. We need to do this early because of the impacts. Let's try to make this in I2 (if not I1). Here's the list of all total 65 runtime files (at deployment, they are combined into edt_runtime_all.js). The first 5 seemed to be the real 'runtime' which should always be included to provide the basic rui support. The left 60 eglx.* are the rui extension parts which may or may not be used by a particular RUI application. I think the way to go might be to further clarify what is the real "runtime" and what is System parts. In terms of app loading, system parts should be treated same as user parts, which is only referenced parts will be loaded. And the edt_runtime_all.js will be runtime code only. "runtime/egl.js" "runtime/egl_mathcontext.js" "runtime/egl_bigdecimal.js" "runtime/edt_runtime.js" "runtime/egl/jsrt/BaseTypesAndRuntimes.js" "runtime/eglx/lang/Constants.js" "runtime/eglx/lang/Dictionary.js" "runtime/eglx/lang/AnyException.js" "runtime/eglx/lang/DynamicAccessException.js" "runtime/eglx/lang/Enumeration.js" "runtime/eglx/lang/InvalidArgumentException.js" "runtime/eglx/lang/InvalidIndexException.js" "runtime/eglx/lang/InvalidPatternException.js" "runtime/eglx/lang/InvocationException.js" "runtime/eglx/lang/NullValueException.js" "runtime/eglx/lang/NumericOverflowException.js" "runtime/eglx/lang/TypeCastException.js" "runtime/eglx/http/HttpRest.js" "runtime/eglx/http/HttpLib.js" "runtime/eglx/http/HttpMethod.js" "runtime/eglx/http/Request.js" "runtime/eglx/http/Response.js" "runtime/eglx/java/JavaObjectException.js" "runtime/eglx/javascript/JavaScriptObjectException.js" "runtime/eglx/javascript/Job.js" "runtime/eglx/javascript/RuntimeException.js" "runtime/eglx/lang/StringLib.js" "runtime/eglx/json/Json.js" "runtime/eglx/json/JsonName.js" "runtime/eglx/json/JSONParser.js" "runtime/eglx/lang/DateTimeLib.js" "runtime/eglx/lang/MathLib.js" "runtime/eglx/lang/SysLib.js" "runtime/eglx/lang/OrderingKind.js" "runtime/eglx/rbd/StrLib.js" "runtime/eglx/rest/RestRuntime.js" "runtime/eglx/rest/ServiceType.js" "runtime/eglx/services/Encoding.js" "runtime/eglx/services/FieldInfo.js" "runtime/eglx/services/ServiceBinder.js" "runtime/eglx/services/ServiceInvocationException.js" "runtime/eglx/services/ServiceKind.js" "runtime/eglx/services/ServiceLib.js" "runtime/eglx/services/ServiceRuntimes.js" "runtime/eglx/ui/SignKind.js" "runtime/eglx/ui/rui/RUILib.js" "runtime/eglx/ui/rui/Widget.js" "runtime/eglx/ui/rui/Document.js" "runtime/eglx/ui/rui/Event.js" "runtime/eglx/ui/rui/View.js" "runtime/eglx/ui/rui/FilterKind.js" "runtime/eglx/ui/rui/MappingKind.js" "runtime/eglx/ui/rui/PurposeKind.js" "runtime/eglx/xml/binding/annotation/Xml.js" "runtime/eglx/xml/binding/annotation/XMLStructureKind.js" "runtime/eglx/xml/Xml.js" "runtime/org/eclipse/edt/eunit/runtime/AssertionFailedException.js" "runtime/org/eclipse/edt/eunit/runtime/ConstantsLib.js" "runtime/org/eclipse/edt/eunit/runtime/Log.js" "runtime/org/eclipse/edt/eunit/runtime/LogResult.js" "runtime/org/eclipse/edt/eunit/runtime/MultiStatus.js" "runtime/org/eclipse/edt/eunit/runtime/Status.js" "runtime/org/eclipse/edt/eunit/runtime/ServiceBindingType.js" "runtime/org/eclipse/edt/eunit/runtime/targetLangKind.js" "runtime/org/eclipse/edt/eunit/runtime/TestListMgr.js" I think the point made in comment 2 fits nicely with some of the other changes we are planning on making in .8 to eliminate the hard coding of our existing "system parts" in various places. I'm not sure we will save a lot of download time by eliminating these files from edt_runtime_all.js, but we do need to start thinking about how to handle these types of files in an extensible way. This bug depends on the decision in Bug 368555 - Investigate modular loading in HTML generator. If runtime & system parts are defined into modules, and the loader is smart enough to load only necessary modules, this enhancement is resolved. I'm moving it from I2 back to the 0.8 backlog because we needs to work on 368555 first. Moving this back to the backlog since we would only focus on the core support of AMD at the moment Separate JavaScript runtime classes into separate modules using AMD. For example, an eglx.lang module, an XML module, etc. This is related to 377026 and similar modules should be defined for each runtime. |