Draft for ?

Discussion about Google AppEngine.

 

In the last few days (Ed.: Apr 30, 2009) I've been playing with Google AppEngine and its Java language support. As its very heart, GAE has the notion of DataStore which is Google's highly scalable BigTable. At the moment you can access the DataStore through a JDO or a JPA API provided by DataNucleus Access Platform, or directly through Google's own low level API. I thought it would be interesting to create an adapter for JCR or have support for the JCR API through the DataNucleus platform. Perhaps, JDO itself, being datastore-agnostic could be a good starting point for this. Of course, one needs to elaborate more on this but the main idea behind this is: store your data in Magnolia/JCR as usual and then let Google worry about scalability issues (they are the major experts in the world in this field after all (smile) ) or integrate you webapp with other services Google has to offer (authentication for instance).

3 Comments

  1. Magnolia International

    There's indeed some work to be on Magnolia's side for this, but the main hurdles, as far as I can tell, would be Jackrabbit and Lucene. I do believe they're aware of this and willing to provide solutions (if they don't do already); it would be interesting to get links to issues reports or discussion from their side here.

    1. Federico Grilli

      I guess that with GAE Lucene would be out of play, as Google under the hoods will do its indexing and use its API for searching. What I had in mind was a kind of JCR façade over Google's datastore API but maybe it's not that great idea. I did some search and found an interesting  thread on jackrabbit+gae integration http://www.mail-archive.com/users@jackrabbit.apache.org/msg11054.html. As it turned out, GAE seems to have many shortcomings at the moment, both technical and possibly legal (something concerning european legislation about where data are physically stored), so that, as far as scalability and jcr integration are concerned, AmazonWS looks much more interesting.

  2. Magnolia International

    Tried this week - couple of roadblocks, mostly related to Jackrabbit/Lucene. We'd need to implement (I couldn't find one) a persistence manager for Jackrabbit; Oak might be worth pursuing. Lucene also causes problems, the first of which being that it tries to set things up in java.lang.management.ManagementFactory, which isn't white-listed, in a static initializer, which would make it hard(er) to swap/subclass. Lucene 4 might alleviate this, but Jackrabbit 2.x is pretty much hardwired to Lucene 3. Oak comes to mind, again.