Sorry I think we probably should have included a bit more background on this issue for you.
When it first came up Dongsheng and myself had a discussion about what the best way to solve this particular issue was.
Over the past couple of weeks as web services have been popping up there have been other similar issues (not with files but with other areas) and its become apparent that we need to allow for these alternative output systems for areas like this.
In the case of many of the webservice situations the best solution (that we could come up with anyway) is to implement a core_renderer_webservice class and a define switch WEBSERVICE_SCRIPT like we have done with AJAX scripts. (there should be a bug for this in the queue for 2.1.1 or 2.2)
In the case of this change I completely agree this is a hack - and an unfortunate one at that.
Because of the desire to get the moodle modile app up and running as soon as possible after the release of 2.1 there is some priority on getting a solution to this sorted and for that reason it was put up for integration.
That all being said I've been looked over the code a couple of times now and I'm not sure this should go in. I think the webservice may be taking the wrong approach.
Presently within Moodle when viewing an users icon it is offloading all of the work to pluginfile.php, arriving at pluginfile.php it is asecertained whether or not the user actually has a profile picture.
If the user has a profile picture then great it is served. If not however pluginfile.php redirects to theme/image.php and in doing so needs to ascertain the theme the should be used to search for the profile picture within.
To do this it makes use of $OUTPUT which has to initialise the theme and output in order to initialise the correct theme at which point we call theme->pix_url.
Really to fix the use of $OUTPUT within pluginfile.php a better solution for theme and output initialisation needs to be arrived at - or we need to come up with a system of working out the current theme for the purposes of redirecting without initialising theme and output.
Both of those routes sound like they would be complicated and not really sutiable for 2.1 at such a late stage making the addition of the set_context call a hack to get things working until we have time to actually look for a solution to the problem.
The second question of course is whether or not the calling code should be responsible for checking if the user has a profile picture or not.
It certainly should be able to check - if nesecary to do so. However in the case of webservices I think (as I don't have complete knowledge of webservices) that this would have a negative effect if not causing errors because it would lead to theem and output being initialised again in place we don't want them.
There is one more point about this code however - now that I look at it should the context be the users context that is being checked 2 lines above this change? perhaps that is the tipped.
This patch gets my +1 providing that context is checked out AND given that we have a blocker issue to find a better solution.
DS I'll wait for your reply about the context.
Eloy if you are want to integrate or reject based upon this extra information feel free too otherwise I will look at it once I have DS's feedback.