It looks pretty good. But I still not sure about the structure.
Here are few things that we have in mind: - Support additional flags for the iframe url. In our case we implemented test harness for gadgets and a flag need to be added to the gadget iframe url for it. Maybe it just overriding IframeUriManager - Return additional iframe style data, for example to pass the scrollable attribute from the gagdet spec to the caller so it can apply to the iframe html node. - We also want to support proxy uri metadata request, and probably same for js uri. Is that in the same handler? if so it might get big, maybe we should break it to sub classes. - For caching benefit of the metadata response, we want to allow a parametrized request. Basically return place holders in the url and let the caller put the values in. I like the fact that the API is basically implemented by annotating the classes. The risk with it is that it is not always clear that a class is part of the API and someone might change the class without realizing the effect on the API. A good example of this is the UserPref class. Can we mark all thos classes somehow to not be modified, maybe even put them is separate library so it will be easy to figure out what is the api? http://codereview.appspot.com/1722041/show
