portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: TODO: Rewrite DiskCache
Date Mon, 28 May 2001 10:14:46 GMT
Johnny Cass wrote:

> Hi,
> 
> If nobody else is already working on this I'll take ownership of the
> todo 'Rewrite diskcache as a Turbine service'. Anything else I need to
> know before starting?
> 


If you are just going to reimplement it as a service, let me commit this 
(euro)afternoon a few changes that couple initialization of 
URLManagerService and Cache before you start.


If you plan to play with it, beware:

The current implementation is not very good :-) . It has been endlessly 
patched from the initial implementation by Kevin, and needs desperately 
a complete rewrite.

State is mixed in JetspeedDiskCache, JetspeedDiskCacheEntry and 
DiskCacheUtils, in a way that makes debugging and development very 
difficult (almost impossible).

There is no clean design of resources according to:
- cacheability (currently local vs. remote)
- writability (currently only local, ie file can be written)
- policies (expiration, etc.)

Also, the management of item state (loading, ...) is done in a 
centralized manner.

I have started development of a completely new implementation, where:

- a Resource class would take care of URI (naming, policies, ...) and 
concurrent access issues, as well as being the interface towards the 
rest of the system.
- Different objects (using the State Pattern) would be plugged in 
resources to implement the actual policies, depending on
    o type of resource (writable, non-cacheable, ...),
    o resource state (stale, idle, loading, expired,...) which in turn 
depends on the type and policies, and
    o access method (protocol, ...).

In this way, we could have a Hierarchy of resources, completely 
decoupled of the algorithm implementations (done through states). This 
would enable
- writing of remote/cacheable resources (through HTTP PUT or WebDAV),
- decoupling of the "file:" protocol for local/writable resources. This 
is particularly important in the long term, as it gives a lot of 
headaches depending on servlet container and difficults distributed 
implementations and/or packed war execution.

These changes would greatly reduce the current complexity, and make it 
easier to develop new resources/policies.

If you have spare time to help with this, we could continue this 
discussion in the list, and work together in these changes.

I have thought a lot in this, and re-implemented it (and throw away the 
result) a couple times. I think this third solution is The Good One :) , 
but I have it almost completely in my brain, where it is of no help.


> - Johnny
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message