Berin,
some latly (inline) comments,
>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
>
>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.
Extended from org.apache.avalon.excalibur.monitor.Resource, I guess.
>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.
>
>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.
>
That makes all sense to me, but I see problems with the different protocols. Of
what kind of Resources do you speak? Remember your "conundrum"...
>
>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).
>Also notice that the second method has the boolean "create",
>that way we can create a resource to write for bi-directional
>pipelines.
>
>COCOON IMPLEMENTATION DETAILS
>-----------------------------
>
>The ResourceManager should be made Contextualizable so that it can
>get the needed reference to the HttpContext object. 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.
>
>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.
Yeah, therefore I will stop know working on the Resource Monitor
in the current design. I see a lawine coming....
>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.
I mentioned this more then one time in this list, but somehow
I don't get an ear here.
>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".
(Be careful the FilesystemStore is used over the whole Cocoon
core. His major role was to serialize for i.e the compiled
Sitemap to the Filesystem. But this things cut be covered
up by a other component)
>Let us decide here and now: Do we need to distinguish between
>Persistent Store and Volitile Store? 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.
Well, for me it doesn't make any sense to have 3 complete Stores on
runtime. Neither for the Event-Store, Stream-Store and Store (which
is really dubious). They seems to me the same! The only argument
therefor was the flexibility to have different Stores for different
Piplines. But somehow that's like repeating himself.
The existing way as the MRUMemoryStore holds objects in
a Persistent state is far away of being optimal. When you
kick the FilesystemStore we have to change this implementation,
either. But that would be good!
For some days I made a RT to improve this with something more
sexy. See the Thread "[RT] Jisp as Store Persistence" for
more information.
May picture of a kool Store system would be:
- A fast memory store for current requested objects (like the
MRUMemoryStore as now). Independent to the Caching implementation,
of course.
- A fast way to write/read objects to the filesystem to
hold them in a persitence way. Maybe like the Jisp implementation
in an indexed data file for fast access!
>Am I making sense? Hopefully we can clean up some cruft that
>we have already accumulated.
Yeah would be cool
Gerhard
--------------------------
Hey! It compiles! Ship it!
--------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
