RSF Discussions Forum

The RSF date picker is loading it's calender icons from an internet domain: akamai.net.

This is it's default behavior as seem in Sakai and begs the question why it's been set up this way.

These icons need to be bundled within the deployed package much like how the other YUI files are.

Hi there - thanks for this report, Lovemore - the behaviour is certainly less than ideal. However, we are somewhat at the mercy of the underlying YUI component implementation (This is YUI's date widget, not RSF's). The behaviour may have changed in a more recent release of the widget, in which case we may be able to upgrade at some point in the future. However, a general movement *is* over towards the use of CDNs (Content Distribution Networks) for rapid serving of static content from dedicated servers - Fluid is looking towards applying this method for some of its more bulky libraries such as TinyMCE and FCKEditor. So it may become more difficult in future to ensure that every file references is served from a local server. Can you explain why the behaviour is problematic for you?
Cheers,
Antranig.

Hi Antranig

I understand that its the default behaviour of the YUI library to act this way.

This has proven to be an issue for us in a few ways:

Page loading is significantly delayed by the icons waiting to be downloaded as this is a slow external request. In South Africa where our internet link is quite slow, such a request may take up to 30 seconds.

The iframe resize also waits for this to complete before being executed. This leaves the user watching a tiny iframe with the nasty scroll bars.

In cases where the downloading fails the icons fail to load up in the date picker, navigating through months/years is not possible anymore. The download failure could be caused by the user not having external internet access from the university's LAN or simply pressing ESC/stop to abort the long request.

Although moving to CDNs may be a good idea for those of us with hight internet speeds/bandwidth/dedicated fiber linkups, it proves quite detrimental for those without.

My suggestion would be to make the use of CDNs configurable within a framework, thereby allowing optional localisation of content where possible.

Thanks, Lovemore - I will look into making this behaviour configurable.