On 2010/12/21 16:02:35, bobv wrote: Bob, thanks for the comments...
The mix of explicit vs. implicit dependency tracking is confusing.
You have an
explicit requirements.addConfigurationProperty(), but the @Source-file
tracking
is implicit via ResourceContext.getResourcesForMethod().
ResourceContext.getResourcesForMethod is not meant as part of any dependency tracking (implicit or explicit)..... It's simply a way for a ResourceGenerator implementing HasFindableResourceDependencies to go and get their resource URL's. It's there to prevent duplicate work, since AbstractClientBundleGenerator.findAllResourcesAndCheckCacheability() needs to go and find all those resource URL's anyway, I moved that process of calling ResourceGeneratorUtil.findResources() out of the individual ResourceGenerators, and do it all up front, since all those resources need to be found anyway for the purposes of checking cacheability (e.g. to compare their lastModifiedDate). This check happens before any ResourceGenerators have been instantiated, since we want to do this check before doing any extra work if it turns out we are cacheable and can bail early.
The SupportsGeneratorResourceCaching interface makes sense, but the HasFindableResourceDependencies smells. Would the HFRD interface be
necessary
if URL dependencies were tracked explicitly?
HFRD dependencies are tracked explicitly via ResourceGeneratorUtil.findResources(), and doing a check on the lastModifiedDate for each URL found.
Where's the escape hatch for staleness, say if an RG wanted to depend
on an
arbitrary external resource?
If an RG wants to depend on an arbitrary external resource, it shouldn't implement SupportsGeneratorResourceCaching, unless it comes up with a scheme on it's own to check cacheability. If we find any resource which doesn't implement this interface, it means we have to invalidate cacheability across the board. If later on, we have a new ResourceGenerator which has external resources which aren't findable via RSG.findResources, but which does have a way to check cacheability, we can develop a scheme for that. Perhaps by adding a different sub-interface in addition to HRFD, which would imply some other way to check resources (ideally without instantiating an RG first). But the present approach relies on being able to inspect things entirely via reflection, without instantiating a resource generator. I'd rather not speculatively develop interfaces for things we don't currently have, no? http://gwt-code-reviews.appspot.com/1236801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
