Re: TODO: Rewrite DiskCache

[Johnny Cass <jo...@epiuse.com>]

Santiago Gala wrote:

%<---------------------------------------------------------------------%<

>
> I read about the "State" design pattern, which is oriented to precisely
> this kind of problem.
> 
> The idea in this pattern is "Allow an object to alter its behavior when
> its internal state changes. The object will appear to change its class."
>  From the "gang of four book".
> 
> If you have access to the book, please read it fully. The idea is:
> 
> The resource (they call it context) will receive "client" calls whose
> result depends on the state.
> The resource will have a internal state ("ResourceState") object.
> The resource will forward those requests to its "ResourceState" object.
> The ResourceState object will know how to deal with the call.
> The ResourceState member instance will be changed controlled by a state
> machine that depends on the kind of resource, for instance going from
> "aStaleState" to "aCachedState", ... as the resource life cycle changes.
> 
> Different kinds of resources (in the resource hierarchy) will be based
> on the different state machines (states + transitions). For instance, a
> cacheable resources has a life cycle of stale -> active -> cached ->
> expired (-> back to active ) -> bad (if something fails). Notice that
> loading *cannot* be considered instantaneous, as in some network
> operations it takes minutes, specially when dns fails or the server does
> not respond. This is the kind of "system freeze" that we tried to avoid
> originally here. The current behavior during "loading" is to wait for
> the load to finish either way, and then repeat the call. An alternative
> implementation could tee the half written cache entry and socket to
> allow for parallel retrieval. Maybe worse is better here.
> 
> If the resource is writable, the "active" state could be splitted into
> "reading" and "writing", and there are new transitions (a bad resource
> can be tried to be written, as it could not be there previously, but
> possibly not to be read until reset). I don't see clearly here.
> 
> A non-cacheable resource could be either be treated as a plain URL
> (states good -> bad) or serialized access (states idle -> active -> bad,
> or idle -> (oneof writing -> reading ) -> bad)
> 
> Different kinds of states (in the state hierarchy) will be based on the
> behavior of client operations like "getReader(), getWriter(), refresh(),
> expire(), etc.)

%<---------------------------------------------------------------------%<

> 
> The most important issue here is to clean the current implementation.
> Maybe I'm going too complex, but I cannot see other way to have it
> right, given the current code complexity and perspectives of use.
> 
> If I'm getting understood, I would welcome any simplification, idea,
> etc. Sorry to everybody for the LOOOONG post, and hope to get some feed
> back. If not, please ask for clarification.
> 
> Also, I don't think there is something similar out there, but please
> point me to similar developments. I think Content Management people can
> be interested in such a engine.
> 

Sorry for my late reply, but I've been thinking about your ideas for the
new DiskCache the way you envision it. I think I'm beginning to
understand where you're headed. 

Please let me know if I can help. I think you should be the one to drive
since you have some very good and specific ideas about how it should be
done, I'll pitch in where you need me (this sounds like such a cop-out?
:) ).

- Johnny

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