Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <cocoon-dev@xml.apache.org>
Subject: RE: [RT] Unification of Source/Resource Management (was Re: Adding
  Resource Monitor to Generators)
Date: Thu, 13 Dec 2001 10:35:26 +0100
Message-ID: <GMEBIBHGAOFGJCDPJANDGEINDEAA.cziegeler@s-und-n.de>
MIME-Version: 1.0
Importance: Normal
In-Reply-To: <3C160459.D4F95445@apache.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

Stefano Mazzocchi wrote:
>
> 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.
>
Hm, some weeks ago we all agreed to move the Source components to Avalon
as they are not Cocoon specific but usable for every project.
I started with this move weeks ago, but never had time to finish it....
You will find all this in the scratchpad of excalibur.
The interface are based on Cocoon, but cleaned up! The missing functionality
is the link to the monitoring.
I really don't want to have monitoring for every Source, I think, this is
simply overkill.
So I could imagine something like a Monitorable interface for a Source
object
with a getResource() method.
I agree, that Resource is a better name than Source, but there are already
many getResource() method throughout the JDK used, so using a new name
shows immediately what's going on.

So I think, we should first finish the work on the Avalon side - this can
either be my proposal above or something completly different - and then
use this in Cocoon.

> > 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.
>
Done in the excalibur scratchpad code (although the name differs)

> > 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.
>
Yupp, but I call it SourceResolver (hey, this is just a teaser).

> > 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.
>
Yupp, Environment is of course removed in the scratchpad code.
But, you might need a base URI. For example in Cocoon you have
more than one sitemap. Now if you only have one ResourceManager
(SourceResolver, Trashcan or whatever) it needs to know to what
sitemap the resource has to be resolved. So here you have a base
URI (the locating of the actual sitemap) and a (perhaps) relative
source definition.

Carsten

> > 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
>


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