> 1/ Have you played with OpenBD on GAE? Yes, quite a bit. Even to the point of modifying the GAE source to attempt (unsuccessfully, sadly) the persistence of CFC properties that are other CFCs as child entities. Got FW/1 up and running under GAE. Used Coldspring to mange both CFC and Java class dependence. Wrote CFC wrappers around the User and Memecache services.
> 2/ Did you find deployment of your CFML easy? Sort of - the "copy this folder and paste it in here" process is not sustainable, with the rapid changes in GAE SDK. I would love to see a "New OpenBD/GAE Project" type in Eclipse that set up a project. > 3/ If you did deploy, have you outgrown your free quota? Not yet, but I am concerned that the use of the VFS might eat up datastore quota quickly. > 4/ Did you have to modify your CFML app much first? FW/1 worked with no issues. Coldspring worked with no issues. A DB abstraction layer of my own design worked with no issues. The app I'm developing is all new code specifically for App Engine, but the plan is that the abstraction layer will allow it to be deployed to, for instance, S3 with mongoDB. > 5/ What could be made easier? Easier? Initial app creation - a project type or ant script, or something to build out a new project is really needed. Right now, making a new project's a bit dodgy. But, I'd like to see the GAE version made more powerful! We need all the new features in OpenBD moved over, the better script support, etc. I'd like to see the implementation of the datastore be more powerful. Be able persist cfc properties that are structs and cfcs. More control over how to interact with the datastore - relationships between CFCs and how to store them. See how much of ACF's ORM syntax could be reused. The biggest issue with low-traffic sites on App Engine is the fact that many requests end up being cold starts - this gets fixed with reserved JVMs, but that costs money. So, focus on quick cold-start. OpenBD's already pretty good - way better then JDO apps. As Steve pointed out - the datastore's going to be the big problem for most people - NoSQL requires a different way of thinking about things - just like a lot of people are struggling with ORM in ACF9. The CFC persistence in OpenBD right now is pretty good for a proof of concept, but it really needs to be able to support CFC properties and struct properties. After that's its just documentation - lots and lots of documentation, sample apps, etc. -- Open BlueDragon Public Mailing List http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon online manual: http://www.openbluedragon.org/manual/ mailing list - http://groups.google.com/group/openbd?hl=en
