dans.blog


The miscellaneous ramblings and thoughts of Dan G. Switzer, II

Vince Bonfanti gets OpenBlueDragon CFML engine running on Google Apps

I thought this would hit the blogsphere a little harder, but Vince Bonfanti was able to get a heavily modified version of Open BlueDragon running on Google Apps. The announcement is a bit buried in a Google Group list for Open Blue Dragon, but the announcement is pretty exciting, because it opens up a new alternative for hosting a ColdFusion application and it's free for pageviews less than 5 million a month.

Here's what Vince had to say about what was required to get things running:

No, this wasn't done using precompiled CFML templates--it's running a
"raw" CFML page just as you normally would.

The Google App Engine (GAE) puts a number of restrictions on Java
servlets, the most significant for OpenBD are: (1) you can't write to
the file system (but you can read from it); (2) you can't create
"background" threads; (3) you can't use any of the java.net.* classes;
and, (4) you can't use any of the java.awt.* classes. There are a
number of other restrictions when accessing the Java class libraries.

Basically, I modified the OpenBD code to workaround these
restrictions. This meant things like not writing out the
bluedragon.xml configuration file, writing logs to System.out instead
of the bluedragon.log file, disabling runtime error logging, etc. It
also meant removing or disabling some features, such as CFCHART,
CFTHREAD, CFHTTP, CFLDAP, CFMAIL, CFSCHEDULE, etc., which won't run in
the GAE environment due to the Java class library restrictions.

We still have a bit of work to do to clean this up to make it ready
for public consumption. I've handed this off to Alan Williamson, who's
going to work on modifying CFQUERY to work with the datastore (GAE
does not support SQL datasources).

While we're working on this, I'd recommend becoming familiar with the
Google App Engine for Java:

http://code.google.com/appengine/docs/java/overview.html

I'd especially recommend becoming familiar with the Eclipse plug-in:

http://code.google.com/appengine/docs/java/tools/eclipse.html

As you can see, there's a lot of modifications that were required and some that may even be deal killers depending on your requirements, but there's still plenty of opportunities to build something exciting.

This would be an excellent way to put an idea to production without investing anything but your time.


TimeWarner's decision to implement bandwidth download caps…

While my current monthly download usage is pretty small, TimeWarner's decision to implement download caps really irritates me. They want to implement caps of 1 GB, 10GBs, 20GBs, 40GBS and 100GBs based on different tiered packages and then charge you overages for every GB over your limit (with the a $75 cap of overage charges.)

They've been facing a backlash about this decision and rightfully so in my opinion.

As I stated earlier, my current download usage isn't very high, but one of the immerging Internet markets in downloadable movie rentals. When the XBOX360 introduced it's Netflix interface for watching streaming movies online, I thought that was a huge jump forward in downloadable movies. Well the Netfix streaming library is still too sparse and doesn't include enough new movies, that will change over time. I certainly see a time in the near future where you'll be able to rent movies purely online.

This is why I'm so irritated with download caps. We're seeing more an more Internet based services succeeding. We're seeing more SaaS applications having success, streaming video taking off and of course iTunes has seen great success. All of these services share one thing in common—they require downloading content to use the services.

If TimeWarner really needs a way to help recover costs, don't limit how much I can download, limit how fast I can download it. TimeWarner has kept bumping up the bandwidth transfer rates, but most people don't need 6Mbps or 8Mbps sustained xfer speeds. I'd much rather see them keep the tiered xfer rate pricing and keep the uncapped download speeds. Let the people who need the higher transfer rates (because their transferring tons of data simultaneously—which is where the real problem lies anyway) and let the rest of us just download the data we need without having to worry about our download usage.

This really makes me hope Verizon bring FiOS to Central Ohio sooner, rather than later. Verizon currently has no plans to cap their download usage and the xfer rates are already much higher than TW. If TW does implement download restrictions, that will be the straw that broke the camels back.

Not only will they lose me as a RoadRunner customer, they'll probably lose me as a Cable subscriber as well.