"Kevin A. Burton" wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Santiago Gala <[EMAIL PROTECTED]> writes:
>
> > "Schwarz, Marcus" wrote:
> <snip>
> > With regards to problem with the handling in the disk cache of external URIs, I
> > will work support for cacheable and noncacheable external URIs, instead of
> > "local" versus "remote", plus configuration support for fully dynamic URIs. So
> > concerns expressed by Ingo about this will be solved <snip>
>
> how are you marking cacheable vs noncacheable???
>
Currently we are using the isLocal() call in DiskCacheUtils. It looks for virtual
URIs (no protocol) and localhost URIs as local, and all else remote.
The current strategy is that local things are not cached, but delivered directly
through URLConnections, while remote entries are cached.
My proposal is that we have a list of regexps in the configuration specifying non
cacheable entries:
- A given server is non cacheable.
- Part of the space of a given server is non cacheable
- All URIs with a given suffix are not cacheable
- all .*/servlet/.* entries are not cacheable ...
The internal marking will be done by having something like:
ResourceStoreEntry is an interface, abstract representation of an external resource.
It would support downcasting for common variants (in example isWritable() and
getWritableResource() that would down cast it to a WritableResourceStoreEntry).
HttpResourceStoreEntry is a concrete, non-cacheable representation for HTTP URIs. A
subclass of this could implement the Writable interface (see down) through simple
HTTP PUT.
FileResourceStoreEntry is a concrete, non-cacheable representation for file URIs. It
could implement the WritableResourceStoreEntry interface
CacheableResourceStoreEntry is an abstract representation of a cacheable resource
with semantics for expiration or refresh.
WritableResourceStoreEntry is an abstract representation of a writable resource with
a getWriter methods to handle character writing (beware i18n, all writing is better
done as characters that as bytes).
DAVWritableResourceStoreEntry is a concrete representation of a DAV resource that can
be written using DAV
...
This has not been implemented yet, but I think we should go into something similar to
that for having the cache as something more abstract. All external resources in
Jetspeed should use this abstraction, to enable other features like caching, maybe
authentication or other similar checks, and to tackle with the problem of parallel
download of the same resource by different threads. Now, all external resources use
the DiskCacheEntry abstraction, but it is not as powerful and modular as the things
we are envisioning for Jetspeed.
I think such a service, when polished, should go into Avalon as a pluggable service
for use in other projects or separate evolution and maintenance of the APIs.
Do you know if some service along the lines, ideally with a transparent management of
a hierarchy of caches (memory/disk) exists already?
>
> Kevin
> - --
> Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
> Cell: 408-910-6145 URL: http://relativity.yi.org
>
> Life is good
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.2 (GNU/Linux)
> Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
>
> iD8DBQE6C4sVAwM6xb2dfE0RAvyoAKCvusAy8ks+lsy65jz49WR+jpVUhACfWI0Y
> VnIjHvWxjpxWvg0lWAh+tPw=
> =5lmK
> -----END PGP SIGNATURE-----
>
> AK-47 SDI colonel terrorist Clinton FSF Khaddafi South Africa Noriega plutonium
> Panama Waco, Texas nuclear supercomputer PLO
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
