Berin Loritsch a écrit :
>
> 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:
I'm not really aware of the issues in IncludeTransformers. Could you
please elaborate more ?
> 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.
+1 to merge both as long as it doesn't enforce the use or ActiveMonitor.
> 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.
SourceHandler methods have an Environment parameter which limits its use
to the context of a sitemap. This is mainly to resolve cocoon: URLs
relative to the current sitemap.
We could duplicate the methods without the Environment parameter and let
the implementations decide whether they allow no environment or not. For
example, CocoonSourceFactory could allow no environment for cocoon://
(absolute URLs) and disallow it for cocoon:/ (relative).
> 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.
If Environment is removed, how can we resolve relative cocoon: URLs ?
> 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.
Why is the HttpContext object needed ? What about CommandLineEnvironment
?
> 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.
Not that much, but after yesterday's discussion, I had a hard night full
of thoughts about all this stuff and even if I now understand the exact
purpose of ActiveMonitor, I'm still afraid of both the size of the
resource Map and the cost of resource scanning on a large site just for
discarding cache entries.
Is it really worth it ? Can't we let entries sleep in the cache until
they are actually used (and checked) or until the MRU throws them out ?
What about the delayed call to getLastModified() I proposed yesterday ?
This could be handled by a DelayedCacheValidity which delays calls to
the filesystem while still enforcing a limited age of the lastModified
information. I'll try to set up a concrete example of that in the coming
days (free time is scarce).
Another thought : the scan period cannot IMO be one and unique for all
resources. There are some resources which can/should be checked more
frequently (e.g. file:) than others (e.g. http:). This configuration
could be part of the definition of the various source implementations.
How can the ActiveMonitor handle this ?
Now let me clearly make the point : ActiveMonitor is a nice idea. But
IMO it should only be used when event listeners do a job that
functionnaly has to be done quickly after the resource changes at the
price of periodic scanning. And I'm not sure "automagic" purge of the
cache fits into this category.
Sylvain.
> 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
>
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
