Skip to main content
C
codeBeastAdobe
Inspiring
January 22, 2011
Answered

shared libraries. Cached BUT if I add another element - does it recache???

  • January 22, 2011
  • 1 reply
  • 574 views

Hi - using shared libraries at the moment for a scalable e-learning course. All the elements are to be used over multiple screens.

BUT if I have to add a new element to that published shared swf - then next time I access my learning program it will have to download the WHOLE NEW shared library - is that right? ie: defeating the purpose in the first place.

So if that is true then the best idea would be to use separate shared libraries. ie: sharedLibraryMusic1.swf   sharedLibraryMusic2.swf for newer mp3s

etc...

Or is this nonsense. ie: A new updated shared library with a "little" new element would not cause the whole swf to be downloaded again???

This is so important as it can make or break the download speeds.

Thanks in advance

This topic has been closed for replies.
Correct answer Andrei1-bKoviI

Browser caching is controlled by request url no matter what asset type is at the server end. Browser (and Flash) has no intrinsic mechanism to compare cached and remote file versions or whether any changes occurred. This means that if you want to make sure that the latest file version is used - you need to recapture the files every time. Unless, of course, you write logic that compares files by, say, versioning them and either having configuration framework that describes what to reload.

1 reply

A
Andrei1-bKoviICorrect answer
Inspiring
January 22, 2011

Browser caching is controlled by request url no matter what asset type is at the server end. Browser (and Flash) has no intrinsic mechanism to compare cached and remote file versions or whether any changes occurred. This means that if you want to make sure that the latest file version is used - you need to recapture the files every time. Unless, of course, you write logic that compares files by, say, versioning them and either having configuration framework that describes what to reload.

C
codeBeastAdobeAuthor
Inspiring
January 22, 2011

So even if I create that framework to test for changes which I doubt I can do then

it sounds like an excellent idea to have various shared libraries just for the fact that it doesn't matter

about file size but the positive is that if I change one library the other remain unchanged.

Would that be a correct assumption?

Also with regards shared libraries - whn some people come out of their browsers they clear their temporary internet folders of everything ie: cached/cookies too. So those people would have to redownload everytime. Is that right?

A
Andrei1-bKoviI
Inspiring
January 22, 2011

"Also with regards shared libraries - whn some people come out of their browsers they clear their temporary internet folders of everything ie: cached/cookies too. So those people would have to redownload everytime. Is that right?"

Cookies do not matter for caching. If they set their browser to clear cache - ALL files will be loaded every time new sessions starts.

"So even if I create that framework to test for changes which I doubt I can do then

it sounds like an excellent idea to have various shared libraries just for the fact that it doesn't matter

about file size but the positive is that if I change one library the other remain unchanged.

Would that be a correct assumption?"

There is no single correct answer or even recommendation to how to deal with RSLs (Runtime Shared Libraries). Each application dictates its own rules that depend on objects availability at the points they need to be consumed. Size may or may not matter (again, answer depends on architecture and internal application business logic).

From the standpoint of choices of what to load and what is changed, if there is no mechanism that detects changes and because of how caching is done - it is only all or nothing approach (either all RSLs have to be loaded per session or one relies exclusively on browser cache).

Change detection is pretty difficult to implement if you rely on client side only because, again, how cahing is handled.

Also, conceptually RSLs must be very stable entities and shouldn't be something that changes often if ever. If they are meant to change often - it is definitely a critical design flaw. Perhaps, this case indicates that what is actually happens is that RSLs attempt to represent data/information/presentation layers. Data MUST EXIST TOTALLY separate from logic and presentation. I cannot stress it strong enough - mixing information, presentation and logic leads to major inefficiencies if not disasters.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices