Alan, That is wonderful and it does bring things closer to the concept.
When the zip is uploaded or a URL for the file(s) is fetched, I figure it will be initially extracted on to that single server in the cloud. Would we have to program with multicast or something for all of the "EXISTING" cloud servers to grab the files from the initial server or would the plugin detect all of the server nodes in the cloud to update all with new files? This makes sense with the WAR and Zip / URL files to simplify the process, but the ultimate area of challenge is the setup of scaling. If your app can use GAE half of your battle is solved (file-wise). If your app can use GAE and does not require a complex relational database structure, then your scaling issue is virtually resolved. If you need to try to redesign your complex relational database structure to use GAE's bigtable, then good luck! I have such a challenge at hand and it keeps your brain's cpu peaking. I know that you all had recommended H2 and another relational database that might work on GAE but they don't seem to have been proven yet and that's quite risky IMO to bet your app on that (right now) for many reasons (stability, performance, etc.) Ok - Alan, you guys are definitely pioneers in my book. Here is a question (not to put you on the line) that could advise US on better designing for the cloud. To narrow it down, lets just deal with GAE since it handles scaling for you out the box without any additional server/plugins. Should we who are designing apps for GAE just move away from relational db designing altogether for now and program from the ground up to use data structures like json / xml to store in their data store and just work with manipulating that data as needed? Ding Ding Ding! - or I just got a new idea - you are already almost there with your cfquery / googlewrite() for GAE... What if we could specify the format to save and retrieve the data as an attribute (<cfquery dbtype="google" format="json"> or googlewrite(car, "MyCarLot", "json"))? Either way, the data would handle all of the conversions in the background and make saving and retrieving data in S3 and GAE easier to deal with like we are used to natively with cfquery the traditional db. We would be writing queries to our own created data structures but if we needed to grab from multiple data structures then that would also be a possibility. The reason is that, if I remember correctly, their blobs are only 50mb each and that may not even be the best place to store the text data. Now, I know that was grossly oversimplified but it was just a sudden thought. I believe that it is you who also has a business where you provide consultation for businesses to scale in just about any cloud platform and also in all of them at the same time for failover reasons. Well, I don't know what you charge for your consulting services but I know that it is a niche and you could easily charge tens of thousands per consultation. You have the expertise it seems already and it is in demand. Offering 1000 users x $37/mo = $37k/mo consistently. A person of your caliber may see that as chump change but we do know that there are more than 1000 CF users out there easily that would instantly switch their hosting to you even if their site might never even scale past one server (lol). But it is just the refreshing thought of knowing that in the event it did need to scale, it would never be brought down to a halt! $37? well just a rough figure. The only support needed would be like what we get right here and they could always opt for premium support. If their site uses up more resources than the max allowed through GAE, then they would have to pay for the extra resources used (CC info must be on file for auto- billing). You would get the benefit of GAE's free usage until you exceed it to get the project started. The service would be offered as a beta until all of the kinks are out. Ok, if this plan does not line up with your overall goals / strategy, then dismiss it. I simply want to throw out some ideas that I think would be wonderful. In Summary the simple vision is... CFML + RDB(with memcache / ehcache to offload) + cloud(with auto- scale) = OpenBD (without a whole lot of cluster/cloud-specific programming.) As I can see, you are already thinking in that manner with the new plugin! Thank you all for you contributions. P.S. Your marketing for OpenBD sux! With all of the advantages that your CFML engine provides, I don't see it out there, really anywhere properly. Maybe, that just happens to be a part of the plan so that the commercial BlueDragon stays in the forefront. Either way, I'm glad that I know about it!!! -- Open BlueDragon Public Mailing List http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon mailing list - http://groups.google.com/group/openbd?hl=en !! save a network - please trim replies before posting !! To unsubscribe from this group, send email to openbd+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
