Fetching user images delays page loading

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use an up-to-date trunk (2.0) installation
2. Set your grid type to "Second Life" in the SLOODLE configuration
3. Register an avatar to your account
4. Visit your avatar page in Moodle (click your avatar name on a SLOODLE Menu 
Block)

What is the expected output? What do you see instead?
The page should load quickly. However, it can be noticeably delayed as the PHP 
script scrapes the SL resident page for a profile picture. Under ideal 
conditions, this would only happen the first time the page is accesssed.

However, it becomes a persistent problem if the avatar image is not found, 
which might happen if the SL resident pages aren't responding as expected, or 
if the avatar is in fact from a different grid, e.g. OpenSim.

I expect the problem will get considerably worse as load increases, as the 
server can only support a finite number of outgoing connections.

It also becomes particularly noticeable if multiple avatars are associated with 
the same account (which we are moving towards supporting). As a result of this, 
serious server admins may complain that the page has inconsistent loads.

Suggested solution.
Rather than attempting to scrape the SL resident pages when a user visits the 
SLOODLE page, it's perhaps best done as a background task, e.g. in the cron 
job. Periodically, all the profile pictures can be updated (although only 1 at 
a time, or the cron job might overrun the script execution time!).

The update cycle should be customizable, and it should be possible to disable 
it entirely should admins desire to do so.

Original issue reported on code.google.com by peter.r.bloomfield on 26 Nov 2010 at 12:48

[GoogleCodeExporter]

It would be good to have image assets for each avatar, so a cron solution 
sounds good.

Original comment by FireCent...@gmail.com on 26 Nov 2010 at 1:00

[GoogleCodeExporter]

Agree it should be a background task that doesn't block viewing the page, but 
HTML already makes loading images a background task that doesn't block viewing 
the page, so maybe with should run with that?

I'm thinking we make the image loading happen when the browser requests it. 
That way if you've just made a change and registered an avatar, you'll get your 
image straight away without needing to wait for the cron.

So we'd have something like:
fetch_image.php?avatar=whoever (Script to serve an image)
1. Checks if it has a recent copy of the image on the filesystem - if it does, 
serves that. (We might have to configure how recent.)
2. If there's no recent image, fetch it from wherever it has to come from, save 
it to the filesystem and serve it.
3. If it couldn't find one, save a placeholder image to the filesystem instead.

Then on the view page, have a profile picture display div where:
1. The div background displays the image on the filesystem if there is one, or 
the original placeholder image if there isn't one. (That way if you're waiting 
for an image to load from an external grid, you'll see the background image, 
which was already on the filesystem so it loaded first.)
2. The foreground image loads from fetch_image.php, which can take its own 
sweet time.

Original comment by edmund.e...@gmail.com on 26 Nov 2010 at 3:11

[GoogleCodeExporter]

Sounds like a great idea.

At the moment it's not actually caching the image files locally -- it's just 
caching the URL of the image on the SL system and giving that straight to the 
user. In theory though, it should be no problem to store avatar images 
alongside other user data in the moodledata folder.

Incidentally, the "view/user.php" and "view/users.php" scripts both need a big 
overhaul, as the code structure is pretty horrendous. (I don't think I've 
really done anything serious to them since about v0.21!) This could be made 
part of that process.

Original comment by peter.r.bloomfield on 26 Nov 2010 at 3:32