Kaiserovi <[EMAIL PROTECTED]> writes:
> David,
>
> yes, the stylesheets do get compiled into internal dynamic trees
> already; in this respect, there's not much work to be done. To sketch
> one possible way I think the caching could work:
>
> The interface would contain functions, say, SablotCache and
> SablotUncache; both would get a URL as the argument. There would be a
> list of URLs to be kept in cache at the moment. These two functions
> would manipulate the list.
>
> Now asking for a document, one would first check the cache for it;
> producing an output document, one would add it to the cache if the URL
> is on the cache list. If it already exists in the cache, it would be
> replaced.
>
> The advantage of this approach is that 1) it allows for cacheing output
> documents, and 2) there's no need to introduce cacheing analogues of
> SablotRunProcessor etc.
>
> It would be easier, at present, to make the cache specific to the given
> instance of the Processor (for some technical reasons). Which is what I
> suggest.
>
> Does this make sense? Any problems?
Well, the above would be nice of course, but I think there should be
an option to get / cache precompiled stylesheets (and also preparsed
XML source documents, since that parsing also takes time) from a more
manual point of view for a number of reasons.
- You don't always work on URLs. For example I work on (mostly)
in-memory buffers.
- You might want to have a lot more control over the caching mechanism
and timeouts, etc.
What you describe sounds like a nice quick-n-easy shortcut and there
is absolutely nothing wrong with it.
The advantages you list:
1) This would certainly be a good thing, yes.
2) This is not necessarily a good idea since it would also limit
caching to a specific processor. In my code I use individual
processors per run (is this dumb from a init/cleanup time point of
view?) since it's a threaded app. I can of course make it use one
processor per thread and have a processor pool. Still per-process
caching is, from my point of view, a limitation not a benefit.
--
[ Below is a random fortune, which is unrelated to the above message. ]
All is well that ends well.
-- John Heywood
