In http://code.xwiki.org/xwiki/bin/view/Snippets/DisplayFormatedCodeAttachment… Clojure <http://groups.google.com/group/clojure> has aJSR-223 implementation according to: http://github.com/pmf/clojure-jsr223/tree/master http://groovy.codehaus.org/JSR-223+access+to+other+JVM+languages http://sayspy.blogspot.com/2009/03/interacting-between-jvm-lang-here-and.ht… Are there any examples, documentation, or suggestions of writing a "script macro" to call a new jar in WEB-INF/lib ?

Any other special magic I should know? Does anything from the above suggest that Clojure couldn't be used as an Xwiki scripting language, replacing cases where Groovy scripting might normally be employed? Niels http://nielsmayer.com PS: Here's examples of easy "scripted java" programming you can do in Clojure (note the helpful parallelism constructs): http://travis-whitton.blogspot.com/2009/07/network-sweeping-with-clojure.ht… http://travis-whitton.blogspot.com/2009/06/clojures-agents-scientists-monke… It could be very useful to employ massive parallelism via such Clojure scripts, which could achieve a xwiki-based web portal performance akin to Yahoo's, Google's, etc. For example, the following describes how Yahoo works -- and would be quite easy to implement this kind of processing "for free" in Clojure with very little code: http://research.yahoo.com/files/pnuts.pdf

The component responsible for multi-record requests is called the > > scatter-gather engine, and is a component of the router. > The scatter-gather engine receives a multi-record request, > splits it into multiple individual requests for single records > or single tablet scans, and initiates those requests in parallel. > As the requests return success or failure, the scatter-gather > engine assembles the results and then passes them to the > client. In our implementation, the engine can begin streaming > some results back to the client as soon as they appear. > We chose a server-side approach instead of having the client > initiate multiple parallel requests for several reasons. First, > at the TCP/IP layer, it is preferable to have one connection > per client to the PNUTS service; since there are many clients > (and many concurrent processes per client machine) opening > one connection to PNUTS for each record being requested > in parallel overloads the network stack. Second, placing this > functionality on the server side allows us to optimize, for > example by grouping multiple requests to the same storage > server in the same web service call. > > Range queries and table scans are also handled by the > scatter gather engine. Typically there is only a single client > process retrieving the results for a query. The scatter gather > engine will scan only one tablet at a time and return results > to the client; this is about as fast as a typical client can > process results. In the case of a range scan, this mecha- > nism simplifies the process of returning the top-K results > (a frequently requested feature), since we only need to scan > enough tablets to provide K results. After returning the > first set of results, the scatter-gather engine constructs and > returns a continuation object, which allows the client to re- > trieve the next set of results. The continuation object con- > tains a modified range query, which, when executed, restarts > the range scan at the point the previous results left off. Con- > tinuation objects allow us to have cursor state on the client > side rather than the server. In a shared service such as > PNUTS, it is essential to minimize the amount of server- > side state we have to manage on behalf of clients.