If you've been following the discussions on the spec discussion group, you probably don't need much more context. If you haven't, I'd suggest heading over there for a bit and reading through the templating discussion threads, as this will potentially become a large issue for OpenSocial as a whole.
In order to effectively support an app model resembling what I've proposed (which seems to be the direction the wind is blowing), we're highly likely to see situations where proxied http requests are even more important than they are now. Many of us have already dealt with apps that immediately execute a makeRequest at load time already. Preload has been an OK workaround, but it's becoming more and more obvious that this doesn't scale so well for a lot of situations. The first step here is going to be ensuring that our http facilities are extremely robust. The out of the box PHP experience makes good use of curl, which is probably good enough, but the base Java fetcher just plain sucks. Paul Lindner had a great implementation of HttpFetcher using HttpClient 4. At the time, I wanted to use it but we got a version conflict with Abdera and gave up (we have our own proprietary solution for use at Google). What I'd like to do is make sure that we have a standard, well-documented http policy. Ultimately, that policy would be fed back into / aligned with eventual standardization in the specification. This includes simple things like adhering to HTTP caching rules as well as more esoteric issues, such as persistent connections and pipelining. This is really a time for brainstorming, since I don't expect any "real" action to be taken on the specification for at least a few months, but I want to be sure that we're getting things right.
