Openfount Library Revisited

Dietrich Kappe, Monday, July 10, 2006 @ 9:00 am

Last week I mentioned the GWT-based Openfount library. I remarked that their Queued Server acted as a proxy for the GWT client on the browser. It turns out that I misunderstood the architecture of the Queued Server. It doesn't in fact allow GWT clients to access S3. Instead, the clients are served from S3 and access the Queued server through S3. To quote from the site:

Openfount supplies the tools to make it easy to develop and deploy an Ajax application to Amazon S3. The trick is how to process requests from clients. The Queued Server solves this problem by using S3 as a queue to process requests. When the Ajax client requests a service, instead of contacting the service directly, the request is written to S3. The client then polls S3 for the response. A server is started up anywhere on the internet to process the requests, and to write the responses to S3, which the Ajax client then picks up.

OK, that's clever. You're service will never get slashdoted because S3 handles all the requests and your servers consume requests at their own pace. Never mind that the effect of underpowered servers means long wait times for GWT clients. Also, a huge deluge of writes to a bucket could really hit your wallet. Consider too this statement from the Amazon doc on pricing:

Network Data Transferred: $0.20 per GB of data transferred. This fee applies anytime data is read from or written to one of your buckets. It does not matter who is reading or writing the data, so consider this when you give public access to one of your objects that may become popular.

I asume that the GWT client needs to know what the key is to be able to enqueue requests to S3, and at the very least, you can either sniff, proxy sniff or use a tool like HTTPLiveheaders to get the S3 bucket and key. The permissions supported for buckets are pretty primitive, i.e. you have a permission to an entire bucket; if I can enqueue a small message to a bucket, I can also upload a 4GB image to it. At best, a malicious user can hammer your in-bucket. At worst, well, I hope they've implemented this stuff so that clients can only write to one bucket and read from another, otherwise how long before the kiddy porn merchants start using your account to distribute their stuff at your expense?

Judging from this little bit of code from the server entry point, it looks like it's open season on both reading and writing to the same bucket:

  public void createBucket() {     
     
         try {     
            Group grantee = new Group();     
             grantee.setURI(ALL_USERS);     
             Grant grantRead = new Grant();     
             grantRead.setGrantee(grantee);     
             grantRead.setPermission(Permission.READ);     
             Grant grantWrite = new Grant();     
             grantWrite.setGrantee(grantee);     
             grantWrite.setPermission(Permission.WRITE);     
             CreateBucketResult res = conn.createBucket(bucket,new Grant[] {grantRead,grantWrite});     
             System.out.println("Bucket created: "+res.getBucketName());     
         } catch (Exception e) {     
             System.out.println("CreateBucket failed, continuing: "+e);     
         }     
     }     
    

Finally, their "Open Source" license contains the following line: "Grace Period" means the number of days that you can use the software without making payment. The grace period is 60 days if not otherwise specified. Now I'm certainly not opposed to making money off of software, but if something isn't Open Source in the GPL or Apache sense, don't call it that. Throw in their licensing fees -- $3/month for up to 100 users all the way to $83/month for a million users -- and this things looks like a good idea that needs to be implemented properly by a real open source effort.

Related posts:

1. GWT Libraries Released – XML, SOAP, Crypto, Amazon, etc.
2. MyGWT Widget Library
3. Javascript Library – JQuery
4. DOM methods, document.write and the art of library design
5. YAACGF – Yet Another AJAX Component GUI Framework

Comments (1)

Software Development

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Dietrich,

   Many of your concerns will go away if (or when) Amazon makes the Simple Queue Service (SQS) available from the same domain name as S3. The only reason we don’t use SQS is because of the well known XmlHttpRequest cross domain restrictions. If SQS were used, there is no advantage to posting spam.

   The post at the AWS blog is informative:
   http://aws.typepad.com/aws/2006/06/openfount_queue.html

   Thanks again for the comments.

   Comment by Bill Donahue, Monday, July 10, 2006 @ 2:33 pm

Leave a comment