In the application that we're developing, there is a significant amount of state that the client side RIA uses that changes very slowly. By very slowly I mean it may not change for a month, may go through a few days where it changes more frequently, and then goes dormant again.
Rather than downloading this state each time the client side Flex application is started, it would be useful to somehow persistently cache that state on the client side. I'm looking for advice as to what the best practice for addressing this need is. I can imagine a couple of possibilities, but I'm sure there are better choices available: 1) arrange for the state to be written out on the server side when it changes in the form of ActionScript classes or .mxml files, and integrated into the core application somehow. When the user starts the application the next day, Flex notices that the application has changed on the server side and re-downloads it. This can be a pretty big hit if the application is large (which ours is likely to be). 1a) A variant of 1, where the generated .as or .mxml file is not incorporated into the main application directly, but is loaded using some kind of deferred loading mechanism. 2) Using some client side storage mechanism, such as SharedObjects, plus some versioning scheme. On startup a quick request or series of requests to check for updates to the cached state is made, and any available updates are loaded. This has the limitation of only allowing 100k worth of state (w/o prompting the potentially naive user) -- this may be sufficient, but it may not. Moreover, whether it will be sufficient or not may depend on the needs of our customers, and may not be something we can predict in advance. Can anyone suggest other options for achieving this goal? Steve
