Thanks for the tips.
This is an internal server so bots shouldn’t be a concern, but certainly the
details of cache update will be important—that’s a detail to which I have not
yet attended.
Today we implemented using in-browser JavaScript to asynchronously fetch the
previews, which we got to
On Thu, 2023-08-10 at 16:00 +, Eliot Kimber wrote:
>
>
> This REST endpoint is called from server-side code that also checks
> for a cached preview and just returns it (avoiding the overhead of
> the REST call), otherwise it calls the endpoint.
I do something similar for fromoldbooks.org
We have successfully implemented the technique described by Christian. We have
a REST end point that takes a database and node ID of a DITA element. If an
HTML preview of the element is present in our cache ( a file system directory
organized by node ID), it is retrieved and returned, otherwise
Hi Eliot,
The following RESTXQ function demonstrates how you can cache RESTXQ
results in the store:
declare
%rest:path('cache/{$a}')
function local:convert($a) {
store:get-or-put($a, function() {
{ $a * $a }
})
};
If the endpoint is called for the first time, the function argument is
On Thu, 2023-07-13 at 19:44 +, Eliot Kimber wrote:
>
> In the context of a RESTXQ handler that is processing a stored
> document to generate HTML From it, I need to do some expensive
> processing and then cache the result for the next time the same
> document is rendered.
For
In the context of a RESTXQ handler that is processing a stored document to
generate HTML From it, I need to do some expensive processing and then cache
the result for the next time the same document is rendered. It doesn’t make
sense to preprocess all the documents to cache the data as part of
6 matches
Mail list logo
