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 17:29:28 GMT
2012/1/20 Skogen, Espen <espen.skogen@jpmorgan.com>:
> I disagree - I believe 1, 2, and 3 is handled adequately in the existing module implementation.
> Multi SDK versioning is also no problem as long as modules are compiled with external
SDK dependencies, and that the parent app is always of a later release then the module.

Even if I used modules in a lot of applications, primarly to allow
incremental loading of functions in large application, I think they
are too limited.

I don't like very much the current implementation because, AFAIK, a
module has to be a visual element on the stage.. instead I'm using the
term "module" here to include a set of compiled class definitions,
visual or non-visual, that can be loaded and unloaded on demand, and
the used to create object instances.. in short, any SWF. Let's call it
"bundle", if you wish.

Moreover, as you point out too, modules are not so easy to unload due
to a number of quircks involving CSS style declarations, embedded
fonts, registered remote aliases, etc. so point 3 is not also not
adequately handled IMO.


> Where this comes short however, is when module A has a dependency on library c, and module
B also has a dependency c - In the current scenario, if the parent app do not have library
c in its application domain, we will need to merge the library in for both modules, leading
to inefficient loading, and potentially conflicts if module A and B needs to communicate and/or
share application domain.
> This is where the OSGI registry becomes relevant.

I'd like to consider "modules" and "libraries" as assets of the same
type: just give me a clean, low level tool to load bytecode at
runtime, and give me the chance to avoid locking that bytecode from
being unloaded due to Flash Player or Flex internal behavior. But let
me choose the best way to describe, handle and resolve the
dependencies among all those modules (by hand, or using a framework).

The OSGI approach could be one of the possible abstractions that
solves this problem.


> There's a number of an issue around unloading of modules - Mainly to do with the Style
chain, I believe, so it wouldn't hurt to look through the StyleManager implementation to ensure
that styles don't stop modules from unloading.
> Another bugbear of mine is the use of StyleManager2 in flex4. I'm not sure what the best
implementation would be, but the existence of StyleManager and StyleManager2 is somewhat smelly
in my mind.
>
> 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: Cosma Colanicchia [mailto:cosmacol@gmail.com]
> Sent: 20 January 2012 13:12
> To: flex-dev@incubator.apache.org
> Subject: Re: OSGi bundle Plugin registry system
>
> 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