On May 30, 2011, at 6:51 AM, Laurens Van Houtven wrote:
I remember Glyph saying something about how that could potentially change/break public API. I understand that reservation, but I don't see how it'd be that bad. Existing code that always immediately returns a resource would still work -- it would merely only use a part of the API it's allowed to use (in this case, it'd ignore the fact that it is allowed to return a deferred). Since a Deferred isn't an IResource, it wouldn't be a legal value to return now, anyway.
The issue is with code that calls getChild, or getChildWithDefault, or any of the APIs that are listed on #3621's description, or anything derived from them. Any kind of resource wrapper will have to deal with these APIs, and there are a surprisingly high number of these kinds of things out in the wild. Every public interface has callers and implementations, and both may exist out in the wild for just about any interface. So, the problem is that we need a new interface. The main other issue which affects IRequest is #288, so it may be worthwhile to land both of these branches at the same time. I've discussed this previously, but the general idea would be: create an integration branch, get #288 reviewed, merge it to the integration branch, get #3621 reviewed, merge it to the integration branch, and then merge the integration branch to trunk (since it would have no unreviewed commits). This would allow us to have only one new interface instead of two. (I am probably forgetting some other tickets which affect IResource and IRequest, others should feel free to chime in.)