> easy way to get Closure doing serious web apps? Ooops. That's supposed to read "Clojure" in the title. Sorry about that.
By the way, I previously wrote: >* 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 ...* * * Wondering whether Google App Engine would be able to host such an application, I check http://elhumidor.blogspot.com/2009/04/clojure-on-google-appengine.html which says: THE BIG CAVEAT Two unusual aspects of the Google AppEngine environment create pretty major > constraints on your ability to write idiomatic Clojure. First, an AppEngine application runs in a security context that doesn't > permit spawning threads, so you won't be able to use Agents, the > clojure.parallel library, or Futures. Second, one of the most exciting features of AppEngine is that your > application will be deployed on Google's huge infrastructure, dynamically > changing its footprint depending on demand. That means you'll potentially be > running on many JVMs at once. Unfortunately this is a strange fit for > Clojure's concurrency features, which are most useful when you have precise > control over what lives on what JVM (and simplest when everything runs on > one JVM). Since shared references (Vars, Refs, and Atoms) are shared only > within a single JVM, they are not suitable for many of their typical uses > when running on AppEngine. You should still use Clojure's atomic references > (and their associated means of modification) for any state that it makes > sense to keep global per-JVM, since there may be multiple threads serving > requests in one JVM. But remember JVMs will come and go during the lifetime > of your application, so anything truly global should go in the Datastore or > Memcache. The first point means closure isn't that interesting on GAE. Any new information to dispel the fact that GAE's Java is "single threaded" ? That seems pointless. Why even use Java, use something like server-side JavaScript, like http://www.freebase.com/docs/acre ? :-) Regarding the second point: why would one be using shared references in code that one wanted purely functional for the purpose of making it decompose into parallel code without needing to worry about any of the issues raised? How could one be doing functional programming if side-effects are happening to the shared references? And how could one expect that code to decompose into parallel code w/o explicitly handling locking on shared references that are being changed? As followup to GAE limitations, see http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 which points to https://sites.google.com/a/wildstartech.com/adventures-in-java/Java-Platform-Enterprise-Edition/JavaServer-Faces/sun-javaserver-faces-reference-implementation/configuring-jsf-20-to-run-on-the-google-appengine > <!-- Disable use of threading for single-threaded environments such as > the Google AppEngine. --> ... If the com.sun.faces.enableThreading context parameter is not set to false (or > omitted completely from the web.xml configuration file) an application > deployed on the Google AppEngine will display a number of different > errors<https://sites.google.com/a/wildstartech.com/adventures-in-java/Java-Platform-Enterprise-Edition/JavaServer-Faces/sun-javaserver-faces-reference-implementation/configuring-jsf-20-to-run-on-the-google-appengine/samples-of-threading-issues> > all > caused by the JSF reference implementation's attempts to construct threads. .... Sadly, current stable releases of Xwiki probably won't be well supported on GAE, either, due to lack of proper database support. http://groups.google.com/ <goog_1248744194084>group/google-appengine-java/<goog_1248744194084> web/will-it-play-in-app- <goog_1248744194084>engine?pli=1<http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1> states: <http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1> > > You cannot currently use Hibernate directly. The differences between the > App Engine datastore and SQL were too great to get the standard Hibernate up > and running under App Engine. App Engine does support JDO and JPA, so you > may be able to convert your Hibernate code to use one of these ORM > interfaces. I believe, future releases of Xwiki will better support JDO/JPA through the XWQL<http://dev.xwiki.org/xwiki/bin/view/Design/XWiki+Query+Language+Specification> effort. Current work, e.g. http://xwiki1.appspot.com/ or http://xwiki1.appspot.com/bin/view/Main/ seems to be based on a non-hibernate-based datastore. -- Niels http://nielsmayer.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
