PRICING

HELP

BLOG

APPSTORE

COMPANY

LEGAL

LOGIN

The deployment engine is one of the major features of the platform. It will enable deploying complex hybrid applications into heterogeneous environments. The powerful dependency management system will detect and inject the correct dependencies on demand and based on usage.

System updated and future changes

With the Initial Layer (IL) configured as the server side (circus apps) and single domain deployment scenarios can be 100% controlled by the publisher, the extension IL and mobile app IL scenarios are not quite similar; The IL section is embedded and gets installed at the client. Consider the following upcoming updates:

1. incrementalLoadPkg does not support multi package, needs to be updated. This is prohibiting the multi background apps from being displayed in the laucher. The simple workaround is in the launcher. [Action: update, ui/ide/cloudstorage/table and rebuild BS, push clean all cach trigger to the target users]

1. The frequecncy of incrementalLoadPackage hitting the cloud needs to be adjustable [Action: update ui/ide/cloudstorage/table and rebuild BS.]

1. Does removing release stop caching? Also editor submit should give the option to re-release. Editor should disable cache/release. With this the latest release will be in sync with individual components.

It is important to note that the BS and PM layers can be updated. The only layer that is not changable is the IL that gets deployed to the client.

Layers

The following are the layers:

• Initial Loader (IL)
• Bootstrap (BS)

Initial Loader

This layer may provide the cache for the bootstrap and packages layer and will load and run the bootstrap (not the packages). This should be implemented depending on the environment type. It is in this layer that the caching will be implemented (not mandatory but it is recommended for performance reasons) and provided to the rest of the system. For samples, see izyware/loader/extensions/contentscript. In addition to caching, this will also create the persistent ID token that gets fed into the bootstrap layer as well as the initial config parameters (such as the start up package for the extension). Finally, it will load the bootstrap layer.

Note that this layer, may run across many different security contexts. For example, in the extension implementation this layer first runs in the contentscript and generates an injectable payload (that will bring in the BS when run) that will run inside the page.

See context detection below.

Bootstrap

Implemented in izyware/appstore/config and izyware/viewer/state, this will auto detect the environment and will generate the state config (url, idtoken, apptoken, etc.) automatically. It will detect current user and the a list of packages (allpackages) to load and run. It has ui/ide/cloudstorage/table embedded in it that gets used for loading packages. The intial package will get loaded through ui/ide/cloudstorage/table incremental loader. If a cacheManager is provided (usually by the IL layer), it will be supplied to ui/ide/cloudstorage/table to grab the bits locally and run the bits.

For direct injection as JS:

https://izyware.com/chrome_extension.js

For example, the app.html page uses it:

https://izyware.com/app.html

For loading through AJAX (comes in handy when implemeting the initial , use:

https://izyware.com/bootstrap1.php

See the following for an example:

https://izyware.com/apploaderwithcache.html

App Layer

ui/ide/cloudstorage/table will always be available for incremental loading of packages (see below). However most apps use the izyware/pkgman/inline/cloud as the wrapper that also uses the cacheManager. Note that this should be added to as a static dependency to the package.

Incremental Loader

It is used to 'load' the packages either from the cache or from the cloud and also to ping the backend for any update:

mdotask.ldmod('ui/ide/cloudstorage/table').sp('packagename', 'pkg1+pkg2+...').

This will

make a list of trigger package by scanning the izyware.token_triggers tables to see if there are once and always trigger packages defined for the current idtoken*

• make a list of the depdendencies (through the izyware.ridep) of the following packages:

- allpackages[0]

- once trigger

- always trigger

- idepkg if needed

• construct the loaded module string by querying the izyware.repositoryitem, using the lists constructed above
• mark the once triggers as processed
• Update the cache if any updates are found

Release Snapshot

For each package, the the packagename + deps (from ridep) will form a list of pkgs which will allow the system to construct the string representation of the modules. The system supports taking snapshots of this over time to allow for release versioning and protect against live changes as they would occur to the system.

Caching Behavior

While caching makes things more complicated, it will have the following benefits:

• Reduces load on the server
• Much more responsive UX, specially needed for toolbars, desktop, etc.

Only the packages that have release snapshots are cached. The timestamp of the release snapshot is used for cache management purposes.

To Inspect the cache manager, console.log the following:

izywarebootstrapsystemconfig // Overall config including cache contents

izywarecacheManager // The reference implementation

transport override

Sites the specify connect-src CSP will reject cross domain GET/POSTing and script-src CSP will reject JSONP loading of incrementalLoadPkg. Also when in non-browser environments (i.e. circus backend) qry/transport/scrsrc will not work. The transport layer can be overloaded using the __runInBootstrapContext in the cacheManager. See the extension implementation for a reference on how this technique is used to remove network tab littering and work around CSP constrains. The circus backend also uses this technique to overwrite the JSONP transfer method.

Context Detection [BS layer]

Context detection is essentially about figuring out what packages (and dependencies) to load and then what to run.

The deployment engine uses the following order to do context detection:

URL: when on site through subdomaining:

http://emptyproject.izyware.com/

DOM: using document.izyware_appid

document['izyware_appid'] = 'izyware+izyware+deps...';

May be used by standlone sites: i.e. izyware.com

URL: when on site through the appid parameter:

https://izyware.com/app.html?appid=emptyproject

May be used for:

- https schemes because the subdomain method wont work with https

- specifiying deps using the mod1+mod2+... scheme since '+' wont work in the subdomain scheme

DOM: query script tag that contain chrome\\extensionmode\\toolbar\\id\\ in id

var ab = document.createElement('script');

ab.id = 'chromeextensionmodetoolbarid' + APPID(true|false for dbg) + '_' + IDTOKEN;

ab.type = 'text/javascript';

ab.async = true;

ab.src = ('https:' == document.location.protocol ? 'https://' : 'http://') +

'izyware.com/chrome_extension.js?' + (new Date()).getTime();

var s = document.body.firstChild;

s.parentNode.insertBefore(ab, s);

OR

This is suitable for injecting into existing context where access or tampering with DOM or the URL is not appropriate. For example, the content script component of browser extensions use this feature to inject into web pages.

Side by Side deployments

The service can handle multiple side by side deployments in the same DOM context. As an example consider the following:

This will cause the deployment service to be launched twice. Each time it is launched it will load one of the contexts.

Events

document.izyOnBeforeLoad = function() {}

Common Package Launch Scenarios

• Directly via bootstrap: In this scenario root module and kernel/storage context is create per bootstrap instance
• Through the AppManager

Inside a running pacakge via importpkgs and ext* mechanism

Launching through AppManager

izywaretoolbar appamanger will launch use the runPkg from izyware/viewer/state. This will recreate the root, so that when the new package is laucnched:

• The root module and hence log, err and dbg configs are not shared.
• The theme is not shared with the laucher context
• The nav and frames hierarchy is not shared, which means that the node, importpkgs, etc. won't be available.

In contrast, when launched by importpkgs and ext render, all of the above is going to be made avilable to the package.

NOTE: the kernel/storage will be shared in both scenarios. Each instance of the bootstrap system (https://izyware.com/chrome_extension.js) gets its own context and kernel/storage. If you are interested in seperate kernel/storage instances, launch your package via bootstrap. However, the intial loader may or may not share the caching storage across different bootstrap instances.

Izyware Help Articles