(On Wed, Jul 22, 2009 at 12:07 PM, Ludovic Dubost <ludo...@xwiki.org> wrote: > > I have a prototype of XWIki partially working with some changes on app > engine http://xwiki1.appspot.com/bin/view/Main/ > > I've made all the servlet / jvm part work as well as the cache subsystem. > The main missing piece is a real storage with support for querying.
Ludovic -- thanks for the reply. That looks quite promising. I guess the "real storage" issue is caused by this:( http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 ) limitation: <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. Will Xwiki support JDO/JPA in the future? Seems like it would be part of the XWQL<http://dev.xwiki.org/xwiki/bin/view/Design/XWiki+Query+Language+Specification>effort, correct? http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-query/jpql-parser/README Mentions "JPA2[2] specification" but it's not clear that other layers wouldn't use other API's. GAE is also looking less exciting now that I look into it more. In a different thread<http://n2.nabble.com/adding-a-new-jsr-223-scripting-language-to-xwiki-(clojure)-td3328361.html>I 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 a massively parallel 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. Because GAE is "single threaded" -- how pointless. 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. Niels http://nielsmayer.com _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
