Forth as a Web Service

This is my latest iteration of developing a Forth system. I started with Forth in .Net, Forth interpreter in JavaScript, Forth to script Google Street View and now Forth as a web service. This latest work builds upon a Python web service framework I developed. It is hosted in the Google App engine and the Forth interpreter is a Python port form my JavaScript Forth implementation.

What I like about this implementation is that I now have a Forth system that is accessible to other systems. Also it stores the state of the Forth interpreter between calls. This allows users to develop Forth programs still using the iterative Forth programming style. It stores state by persisting the stacks, and the user dictionary using the Google App Engine data store. These structures are pickled using Python to ease storing and retrieval. Developers can choose to pass in a session value to the web service to identify a Forth interpreter instance to use. This is beneficial so you do not have multiple callers manipulating the state of the same Forth interpreter instance and getting unpredictable responses back.

To the Forth Web Service Console

MVP Pattern in JavaScript

I have been using the Model View Presenter (MVP) pattern when building some ASP.Net applications and I thought it would be an interesting experiment to try and implement that pattern entirely in JavaScript.

In this experiment, the JavaScript page would be laid out in the following manner.

1. The View is a JavaScript class that encapsulates the interaction of the UI components of the JavaScript through the DOM. Usually this is an interface plus a class implementation to do this in programming languages like in .Net. However since JavaScript doesn’t have interfaces, I just went with a straight implementation. Since JavaScript is a dynamic language it worked out the same.

2. The Model is a web service, a CacheService discussed in this post, and handles getting and retrieving data from the data store.

3. The Presenter is a JavaScript class that takes in an instance of the View. It also encapsulates the Ajax logic used to read and write data from the Model.

Granted this is a very small application, but I really liked the way application ended up being organized. It seemed very clean, easy to follow, and common routines were easily reusable. For example, getting and setting values, and enable or disabling the UI while in the middle of an Ajax call.

I think the next step is to try this pattern out on a larger more complex JavaScript application.

Check out the JavaScript page.

All the code for the implementation of the MVP pattern is embedded within the page so one can just view the source from the browser.

Calling a Python Web Service from JavaScript

This entry is a continuation of a caching web service developed using a Python Web Service Framework discussed in this post. Here I am experimenting with invoking that web service from JavaScript using Ajax. I have used Ajax before but never to interact with a web service directly. The only thing that was really new here was adding logic to parse out the SOAP response and a general routine to discover and interpret SOAP faults.

In the JavaScript page you will also notice I have mentioned organizing the JavaScript to conform to the Model View Presenter pattern. I plan on including an entry in coming days to discuss that aspect of the page further.
Update Added this entry on 5/13/09. Check it out here

I didn’t include any source because it is just as easy to view the source of the JavaScript page to see what is going on.

On to the JavaScript page!

Python Web Service and the Google App Engine Data Store

In the last post I discussed and provided code for a Basic Python Web Service Framework for the Google App Engine. This post continues on that work and provides an example of a simple service built in that framework which interacts with the Google App Engine’s data store.

The service is a caching service. It allows users to store a string value referenced by key; a hash table using the Google App Engine’s data store. The operations allowed on this service are get a value by a key, set a key value pair, and delete a key value pair. Two additional operations are get the key value object as Xml, and get the key value object as JSON. Together all these operations provide an example of each of the CRUD operations on the data store. Further, each one is wrapped in a transaction, so there are examples on how to code for transactions as well. The one thing that is missing is an operation that performs a query using GQL.

Link to the source for the CacheService

Link to the live web service on the Google App Engine

I have built a simple JavaScript application to call the service. This is why the operations to get the key value object as Xml and as JSON are included in the service. It was a fun experiment to try and call the web service from JavaScript using Ajax. I think it provides a nice simple interface for users to experiment with the service.

CRON Job
I have implemented a Google App Engine Cron job to delete entries after a defined period of time in order to add expiration to the service. All it does is perform a GQL query looking for entries that are older than week, via the update_date property, and deletes them. You can see the logic for it within the expire method on the CacheService. Should note that method is not exposed as a service call and for the cron job it is getting called directly.