Before I did the zip2html posting last December I had a solution without the cool execution of an attached stylesheet.

I did extract all files needed, and because storing on local filesystem was not possible without going through xml-mgmt,
made use of a self-implemented "file cache". In difference to normal backend response caching in that scenario the
files are available on the "client side" and caching these was not that easy.

But because I finally came up with a purely attachment based solution for zip2html tool there was no need for the "file cache" anymore.

I had discussions with a Techsales colleague at that time, and he just told me that he needs to cache client data and asked for my cache.

So I seperated out my "client request cache", reworked it and post it here today for anybody who needs to cache client data on DataPower.

By default the document count is 5000 (which you may want to reduce) and the document cache size is 0 (disabled, you need to increase).
The maximal size of a document cache is 161MB, but keep in mind that anyconfigured document cache memory is lost for transactiuons.
I did set document caching to fixed with time to live (TTL) of 59 seconds for URLs matching "*cache*", all other URLs are not chached.

Before going into the details, that is what "you get".
First we cache (POST) the document with content "test123" under URL .../cache/0001.
Then we retrieve it (GET) two times successfully.
The big image Screenshot.png gets cached under URL .../cache/002 then.
And two more get requests get it back from the cache.
The "word-count" (wc) commands prove that the received and original sizes (273657 bytes) are identical:

And this is screenshot of "Status->XML Processing->Document Status" status provider after above commands.
Here we can see that the small "test123" document gets cached as one document.
The big Screenshot.png gets cached as 3 parts (only last part less than 127.000 bytes in size).
And the concatenated complete compressed base64 string for retireval under URL .../cache/002:

Again, before going into the details, find a 3.8.2.6 domain backup and its zip2html tool output attached here.

The three files stored in local:/// directory of that domain (shown further below) are available inlined in the "(all)" link of zip2html file!

Since HEAD is not really helpful in getting client data put into DataPower document cache, only GET remains.
So a caching service on DataPower needs to "send" the client data using GET to a helper service on the same box to do the caching.
Unfortunately the HTTP header size is limited, so although compressing the client data first it may not fit into a single request.

The solution I have implemented is this:

Client:

sends some (binary) data of arbitrary size to DataPower for caching under a specific URL

extract the 127.000 bytes received by a "part" GET request and "return" them which stores them into document cache

when receiving a "combine" GET request from 1st service, reading all 127.000 byte parts for that request from
document cache and "return" their concatenation, which stores the whole compressed document into document cache

So what the file cache does is storing files from the client side into DataPower document cache circumventing the problem
that you cannot cache files by a POST request -- that's all -- see the demonstrations above, and try out yourself !

I did import and test the above attached backup on 3.8.1.20, 3.8.2.6, 4.0.1.4 and 4.0.2.5 firmwares.

(for me this is the first time, that all rule "matches" are HTTP-method matches (for GET or POST))

Today's posting deals with the famous n-queens puzzle, a generalizition of the 8-queens puzzle.

In this puzzle N queens need to be placed on a NxN board, so that no queen threatens another.

The screenshot you can see above is part of the output the stylesheet n-queens.xsl.xml will create in your browser.

It will create all n-queens solutions for 4<=N<=9.

A solution is called distinct in a set of solutions, if no other solution can be retrieved by rotations and/or mirroring of the solution.These are 1+2+1+6+12+46 = 68 distinct solutions, and 2+10+4+40+92+352 = 500 solutions overall.

The stylesheet allows to specify, whether the 4 little .gif images used to compose the diagram should be inlined base64 encoded by "data:" scheme or not.

Without internal images the size of the generated HTML page is 1.95MB, with internalImages set tu true(), it becomes 9.15MB.

The advantage of the internalImages HTML page is, that it can be saved as single HTML page without any external references.

Just for fun I opened n-queens.xsl.xml on a last century Thinkpad 600E with 288MB(!) of main memory.

The Firefox 11 under Windows XP used 53MB of the available 63MB free memory for n-queens.xsl.xml, and completed in 3:10min!

Good that my current Thinkpad W520 under Linux does the same in Firefox in 5sec, in Chrome in 3sec ...

it uses <xsl:variable name="blah0">...</xsl:variable> <xsl:variable name="blah" select="exslt:node-set($blah0)"/>technique to easily allow for repeated processing of node-set results produced in between;this technique is NOT needed by DataPower XSLT processor, because that does not differentiate between XML trees and RTFs (Result Tree Fragments)

it uses single digit numbers to identify a queens column for ease of board:mirror and board:rot90 operations;this restricts the stylesheet to at most the 9-queens problem

n-queens:sieve template is really nice recursive template for sieving out threatened fields after placing a next queen

because the output grouping is based on really complex mirror and rotation operations, duplicate elimination is done "by hand";I saw now option on how to make use of Muenchian grouping

there are some glue templates for converting a solution to board notation in order to reuse previously posted board drawing templates

it allows to use "data:image/gif;base64,..." encoded images instead to refer to those in "gif/" sub directory

and, last but not least, it really made fun to create this solution and see the nice output it generates!

Now if we look at the English board, we have 32 pegs and a hole in the initial position:

Of course we could have an XML file stored for each possible position.
And a xml-stylesheet processing-instruction would instruct the browser which stylesheet to use for drawing.
Of course each field would have a hyperlink associated which links to "the next" position.

There is one principal problem with this simple approach:
We have 33 fields, and each can have a peg on it or not -- this makes 2^33 or more than 8 billion different positions!

I do not have enough webspace to store 8 billion XML files on my private web server!

And even if it would be possible for the English board, the Diamond board has 45 fields and 2^45 = 35,184,372,088,832 positions ...

So it should be clear that a static XML file approach is not possible.
Based on code snippets I already used in posting "[xsl] support of stylesheet embedding for ALL browsers"

Since the execution is completely client-side by the browser Javascript XSLT engines, each resource (draw.xsl, xslt-events.js, board HTML, some .gifs)
need to be loaded exactly once, and network connectivity is not needed afterwards.

peg-solitaire also works fine on the Opera mini web browser of my KS360 cell phone!

See photo taken (with my cell phone from that of my son) at bottom.

draw.xsl allows for two modes:
* "play" mode, where you can see the "stop" button at bottom right
* "edit" mode, where you can see the "play" button at bottom right (create your own initial configurations!)

In addition the 5 graphical buttons allow to go to the start positions of the 5 different boards directly.