incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cosma Colanicchia <cosma...@gmail.com>
Subject Re: OSGi bundle Plugin registry system
Date Fri, 20 Jan 2012 13:12:23 GMT
I think we should first identify which low-level requirements that any
module system may want to address.

I see the following ones, in ascending order of complexity:

 1) bootstrap-time incremental loading of modules
 2) late and on-demand incremental loading of modules
 3) support for on-demand unloading of the modules
 4) support for sdk multi-versioning (modules compiled against
different SDK revisions)

I think that the current RSL features only address requirement 1.

AFAIK, many of the existing frameworks (e.g potomac) allow to go up to
requirement 2, and in this level we usually find the need for
additional high-level facilities such as registries, IoC and
dependency management features. However, my personal take is that
those facilities should not be embedded in the SDK but left open to
the application frameworks: I'd prefer to have only the low-level
handles in the SDK and in the Player to let these frameworks implement
their abstraction.

Going to level 3 is currently not simple, partially because of
limitations at the Flash Player level (e.g. the remote aliases
registry managed at the SecurityDomain level, thus potentially related
to multiple ApplicationDomains with conflicting class definitions, or
the impossibility to remove entries of this registry once added).

Level 4 is, on the other hand, pretty tied to the Flex SDK
implementation (it was the scope of the marshall plan).


I think that a discussion about the scope of any modules support
system could help us to better define the problem.


Cosma


2012/1/19 Skogen, Espen <espen.skogen@jpmorgan.com>:
> In simple terms, the benefits would be this:
>
> Your main application loads a number of modules provided by a number of dev teams.
> Each module has a number of dependencies, and you do not know what those dependencies
are at compile time of the parent app, so RSL is not an option.
>
> The registry allows loading of the dependencies of the modules, adds them to the application
domain, and keeps a record of the dependency. When the second module depending on the same
dependency gets loaded, there's no need to load the dependencies, because they already exist
in the app domain.
>
> So in effect, it allows an on-demand rsl-like dependency loading behaviour which is supported
on a module level instead of just at the application level.
>
> There are however issues around memory management and unloading which needs to be addressed,
so although theoretically it sounds quite simple; there's a number of implementation issues
that needs some thought. Haven't spent much time on this, but it would definitely be worth
investigating.
>
> E:)
>
>
> Espen Skogen | Vice President | IB Tech Market | Investment Bank | J.P. Morgan | 125
London Wall, EC2Y 5AJ,  London, United Kingdom | T: +442077420836 | espen.skogen@jpmorgan.com
| jpmorgan.com
>
>
> -----Original Message-----
> From: Web DoubleFx [mailto:webdoublefx@hotmail.com]
> Sent: 18 January 2012 17:49
> To: flex-dev@incubator.apache.org
> Subject: RE: OSGi bundle Plugin registry system
>
>
>> From: espen.skogen@jpmorgan.com
>> This is the approach I've used in the past as well. Gotta love Parsley
>
> Sorry, for my english BTW, but can you explained what the gain with a registry ?
>
> If we have a bootstrap, we'll loose the possibility to optimize RSL loading (like in
Gravity), and I wonder, what can bring us a registry ?
> Frédéric Thomas
> This email is confidential and subject to important disclaimers and
> conditions including on offers for the purchase or sale of
> securities, accuracy and completeness of information, viruses,
> confidentiality, legal privilege, and legal entity disclaimers,
> available at http://www.jpmorgan.com/pages/disclosures/email.

Mime
View raw message