Paul,
  Could you please clarify your question - it seems that there are number of issues that are mixed up here. First, there is no issue of RSL caching in the browser unless you specifically enable some expiration scheme.
 
I have seen people loading multiple applications side by side - using the same RSLs - that is essentially the question if you want to isolate your runtime libraries in case of versioning in the future - that would essentially hurt performance
 
Finally, there is an issue of loading RSLs in the root appDomain - essentially you do not have a chance to do reloading of the classes till the application startup. Also, there is obvious problem with versioning.
 
Seems we are done with the client - now the question is how to build RSLs so it is the smallest, most recent, and up to date one.
 
That's were it breaks in the beginning. Essentially, if you are using dynamic instantiation of any class in the RSL, the main application would not know whic objects to initialize/which dependent classes to include. One solution we are using is to build self initializing modules and use them instead of RSLs that would of been extracted out of SWCs by the build process.
 
HTH,
Anatole Tartakovsky
 
 


 
On 9/26/06, Paul Spitzer <[EMAIL PROTECTED]> wrote:

>some concerns about potential RSL caching and how to overcome that
>(I think it can be easily overcome with a proper rollout strategy)

I'm curious to hear what your plan is to deal with the caching of
RSL(s). Or how others deal with it. Any suggestions?

derrickgrigg wrote:
> I actually was concerned about the HOW and the WHY. I wanted to find
> out why doing it that way was a good solution or why someone else's
> solution would be better or more viable. And if the proposed
> solution was good, was how I intended to implement that solution the
> right way.
>
> I completely agree that having Abstract and Interface classes just
> to accomplish modularity is basically creating a code management
> problem. The only reason it was seriously being considered was to
> allow the development of seperate module swfs, that need to use the
> same base classes (ie models, command and value objects), without
> having to worry about code duplication and errors/conflicts when
> module swf are being loaded in the main shell application.
>
> I've had problems in the past with Flash and RSLs plus I still have
> some concerns about potential RSL caching and how to overcome that
> (I think it can be easily overcome with a proper rollout strategy),
> so I was a little hestitant to pursue that idea. However, from your
> post and Erik's (plus my own nagging suspicion), I think having the
> base code in an external SWC and using that as an RSL is the right
> was to go.
>
> Derrick
>
>
>
>
>


__._,_.___

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com





SPONSORED LINKS
Software development tool Software development Software development services
Home design software Software development company

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___

Reply via email to