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.
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.
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.
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.
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".
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.
Am I making sense? Hopefully we can clean up some cruft that
we have already accumulated.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
