It is essential to keep the different layers straight here.
The example is somewhere at the level of the pipeline api or probably sitemap
api implementation..
Here caching is a question of the implementation of the components.
It actually will depend on different implementations of generators,
transformers or serializers (cache-enabled or not).
URL cache support is an issue for implementing the cache support within a
component.
e.g. the FileGenerator might use .getLastModified() or alike methods for
determining cache control info for its own cacheability...
Also the transformer might use such information for determining whether the
script used is still valid.....
Thus, it is not really surprising that the example will not really benefit from
cache parameter info methods provided from URL
implementations - it's a different layer.
However, e.g. when trying to decide whether the "cached" result of the
FileGenerator() *component* is still valid, it will come handy
to have information on whether the file did change in between.
Rainer
Ralph Goers schrieb:
> Consider this:
>
> URL baseUrl = new URL("file:///C:/temp/");
> Pipeline pipeline = new NonCachingPipeline();
> pipeline.addComponent(new FileGenerator(new URL(baseUrl, "xyz.xml"));
> pipeline.addComponent(new XSLTTransformer(new URL(baseUrl, "xyz.xslt"));
> pipeline.addComponent(new XMLSerializer());
> pipeline.invoke(new InvocationImpl(System.out));
>
> This simple pipeline has these potentially cacheable components;
> xyz.xml, xyz.xslt, the result of the XSLT transformation, and the final
> result of the pipeline. As it relates to the pipeline I don't see how
> the URL.getLastModified() really helps as it could apply to any of these
> items, two of which aren't even URLs.
>
> Ralph
>
> Steven Dolg wrote:
>>
>>
>> Carsten Ziegeler schrieb:
>>> Steven Dolg wrote:
>>>> How about:
>>>>
>>>> URL url = new URL("some url");
>>>> UrlConnection connection = url.openConnection();
>>>> connection.getLastModified();
>>>>
>>>> Not sure it this really works in all cases, but appears to be quite
>>>> suitable and easily extensible.
>>>>
>>> Yes, this works for many cases, but not for cases like where you have
>>> an expiry date etc. What do you mean by "easily extensible"?
>> url.openConnection() actually returns a subclass of URLConnection
>> depending on the protocol of the URL.
>> So own protocol implementations can return own subclasses that
>> implement this (and other methods) accordingly.
>> And - at least theoretically - provide additional methods for handling
>> specific stuff, e.g. expiration dates.
>>>
>>> Carsten
>>>
