Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3C160459.D4F95445@apache.org>
Date: Tue, 11 Dec 2001 14:04:25 +0100
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Unification of Source/Resource Management (was Re: Adding
 Resource Monitor to Generators)
References: <LDEKKGCNJLEPFDOEIHFDKECPCKAA.g-froehlich@gmx.de>
 <3C14BF38.67E2A955@anyware-tech.com> <3C14FAE6.5050700@hartle-klug.com>
 <3C150564.8020307@apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for pointing this out!

Berin Loritsch wrote:
> 
> For those of you who want to make XIncludeTransformer and CIncludeTransformer
> cacheable, we have to address some major issues.  One of which is that the
> base Source interface does not permit cacheability.  Also, we want to make
> the Cache invisible to the rest of the system.  Therefore, I propose some
> organizational changes:
> 
> 1) All Sources must be made a Resource to allow notifications if the source
>     has changed.  The best option would be to merge the concepts.  I personally
>     like the name Resource as it does not cognitively restrict you to read
>     only resources.

Totally agreed.
 
> 2) The URLFactory must be removed, and it's functionality merged into SourceHandler.
>     The SourceHandler must allow the mapping of protocols to the Resource types.
>     The new Component should be called a ResourceManager.

Good choice.
 
> 3) The ResourceManager is responsible for obtaining the handle to the resource
>     in question.  It makes sure that the resource returned is current, and
>     manages the Resource cache entries.
> 
> 4) All accesses to resources go through the ResourceManager.

Sounds good.
 
> The interface should be something like this:
> 
> interface ResourceManager {
>      getResource(String uri) throws IOException;
> 
>      getResource(String uri, boolean create) throws IOException;
> }
> 
> It is *intentionally* simple, and does not supply "base" URIs
> because the configuration should handle what the "base" URI is.
> Notice that there is no Environment object (which is decidedly
> Cocoon centric and muddies the concept of what it should do).

good.

> Also notice that the second method has the boolean "create",
> that way we can create a resource to write for bi-directional
> pipelines.

Hmmm, don't find myself resonating this this. Can you elaborate further?
 
> COCOON IMPLEMENTATION DETAILS
> -----------------------------
> 
> The ResourceManager should be made Contextualizable so that it can
> get the needed reference to the HttpContext object.  

absolutely

> It should be
> made Configurable so that it can understand how to map protocols to
> Resource classes.  It should work with the Cache system and the
> Monitor system.

correct
 
> If the Resource type is Cacheable, then the ResourceManager will
> take care of the Cache plumbing.  IOW, it will returned the cached
> Resource (if available), or create the new reference and add it to
> the cache.  Also, if the Resource is used in the caching system,
> it is added to the Monitor, and the Cache system is passed as the
> PropertyChangedListener--either that, or a different object that
> manages the interaction between the two is used.
> 
> Confused yet?  Good.
> 
> STORE UNIFICATION
> -----------------
> 
> Currently, we have three implementations of Store, and only one
> is used.  To make things worse, there are three roles to which
> the one implementation is referenced: Store, Stream-Cache, and
> Event-Cache.  I hope you realize that with 3 different roles
> in the system, there are at least 3 different instances--even
> if they are declared ThreadSafe! That means you have three
> instances of MRUMemoryStore all pointing to the same repository!
> 
> There are bound to be resource conflicts.  This must be fixed.

Totally agreed.
 
> In order to remedy this situation, we have to refine exactly
> what the store contracts are.  We used to have two ideas:
> Persistent Store, and Volitile Store.  The implementations
> were FilesystemStore and MemoryStore respectively.  However,
> with the flexibility of the MRUMemoryStore, this is no longer
> necessary.  We simply only need the role of "Store".

This is what I've been proposing since my very first RT about caching
(which largerly when unimplemented, but I still have them in my todo
list!). A 'good' store implementation should know how to manage its
resources in such a way that optimizes use and overall performance.

having two store behaviors overlaps concerns.

> Let us decide here and now: Do we need to distinguish between
> Persistent Store and Volitile Store?

No, I don't think so. It's not hard to come up with heuristics that take
care of this and adapt to the current caching needs (see that RT for all
the algorithms that implement that!)

> I do not think this is
> necessary any longer.  There is absolutely no reason to
> differentiate between Event and Stream storeage with the
> Store interface--when both implementations are the same.
> 
> Am I making sense?  Hopefully we can clean up some cruft that
> we have already accumulated.

Definately +1, I'm very happy to are bringing this further.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org