Summary
Most imperative languages are designed to express control flow explicitly. Unfortunately, this makes it difficult to program in a more reactive style. Proposed are two constructs, Generators and Grammars to help ease the burden.

The public review of the Streaming API for XML (StAX) has been released.  This is the standardization of a new kind of way of interacting with XML.  The current ways are based on DOM and SAX.  DOM based api's tend to be more flexible however at the cost of creating the entire document tree.  SAX is extremely efficient however it tends to be more difficult to program in a event driven style.     The name chosen in not entirely accurate since SAX is also a streaming API. StaX is a "pull" based streaming API as opposed to the the "push" that you find in SAX. 

StAX and SAX performance I would expect should be roughly equivalent as evidenced by these benchmarks. The claimed advantages of a "pull" form is that it is easier to program in.  However, I do find it very interesting that imperative languages make it difficult to write programs using "push" based or event driven programs. 

The answer is that imperative languages are designed to express control flow explicitly.  On the othe hand, for event driven API's the control flow is in a large part controlled by the event processor and the programmer is required to write code that's more reactive. Writing reactive code is definitely more difficult because you can never assume what will happen next.  Though, I'm going to go out on a limb to say that reactive code is actually more scalable and flexible.

I have two ideas on how to make programming to Event Driven API's easier.  One is to make the specification of state machines much easier.  The way to do this with a programming language is to introduce what is called Generators.  Generators were popularized in the programming language Icon.  It allows the definition of functions that can be called multiple times but return multiple results.

A second approach is to make the specification of grammars much easier.  If you've taken Automata Theory in college you know that state machines are equivalent to regular expressions, and regular expressions is a language that is weaker than context free grammars.  The approach then is to define state machines in terms of context free grammars.  This is exactly what a tool like Joost is doing. Joost is an implementation of the Streaming Transformations for XML (STX).

STX is should not be confused with StAX.  They both are designed to tackle the streaming xml problem however STX tackles it in a much high level way.  STX however doesn't need to use a "pull" API.  It leverages SAX and makes developing XML transformations as easy as XSLT.  Actually, I like it better, since it gives an imperative flavor as opposed to the functional flavor demanded by XSLT.   Matter of fact, if you're thinking about scalability, this is possibly the best way to fly.  I had it crunch through a 29 mb file without the VM going over 8 mb, such a task will put a DOM based XSLT processor to its knees!

Event Driven API's also tend to be more loosely coupled.  If you consult this table you realize that it supports two properties. That is asychronous and lazy evaluation.  So even amidst the call away from "pull" driven API's as shown by (StAX), "push" driven API's will continue to become more prevalent.   

In summary, Event Driven API's are more difficult to program in simply because imperative languages were not designed for them.  The use of both Generators and Grammar based approaches should make it much easier.  The main benefit of an event driven style is better scalability and a loosely coupled approach.

Talk Back!

Have an opinion? Readers have already posted 2 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Carlos Perez adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Carlos E. Perez has been an object-oriented practitioner for over a decade. He holds a Bachelor's Degree in Physics and a Master's Degree in Computer Science from the University of Massachusetts. He has polished his craft while working in IBM's Internet Division and IBM's TJ Watson Research Center in Hawthorne, New York. He now works for a startup 1/100,000th the size of his former employer. He writes about topics covering emerging aspect and object oriented paradigms, loosely coupled architecture, open source projects and Java evangelism.