I just attended AjaxWorld 2008 in San Jose, California. The theme of this conference was "2008: Decision Year for RIAs". Here is a quick summary.

• The first day keynote was by Scott Guthrie of Microsoft. Scott manages the development platforms including Silverlight. He gave several demos. The first one showed ASP .Net MVC (Model View Controller), JQuery, and Visual Studio 2008. The second demo was Silverlight and RIA-based development. Silverlight claims cross-browser, cross-platform plug-in. The Linux version is done with Novell. Most of the examples were on video streaming at sites such as NBC Olympics, the DNC (Democratic National Convention). He claimed the NBC Olympics had 70 million streams in 14 day period. AOL mail was another example using Silverlight. Some SAP front-ends are now using Silverlight. He claimed one of every four PC's now run Silverlight, kind of hard to believe, specially when Silverlight Release 2 was launched lat week. I wrote a response to a blog post on this. Microsoft deserves credit for "adaptive streaming" on varieties of line speeds ranging from 250 kbps to 2 Mbps. They clearly focus on beating Adobe's Flash player in video streaming. The business application part of Silverlight is weak on examples and functions, but high on claims. Silverlight claims multi-language support like C#, VB, Python. They claim rich query of data and local caching. The download is 4.6 MB and everything fits in that (includes 100s of built-in controls). For example, they have HTML API for programming pure HTML apps. All functions like calendaring have skinnable controls. Visual Studio is their IDE. The combination of VS 2008 and Microsoft Expression addresses the designer+developer community.

• Matt Quinlan from Appcelerator stared by saying "users may times don't now what they want. If Ford would have asked users what they wanted, they would have a said 'a faster horse'". Appcelerator provides a framework to speed up Ajax development. It provides a higher order expression language that generates Javascript. He said Javascript is "mountains of code" and pointed out that Google Map has 6535 lines of Javascript code. He derided Javascript as tedious, error-prone, boiler-plate stuff. It was interesting that many presenters showed Ajax frameworks to speed of development.

• Oracle made a presence this time. They showed their existing tools such as JDeveloepr and ADF (Application Development Framework) all using some new technology. It's "old wine in a new bottle". There is no front-end client-centric RIA story. They are from a Java server-centric culture and are sticking to that.

• Adobe CTO Kevin Lynch presented on day 3 early (poor audience) and I missed that, but supect he glorified Adobe Flex and AIR.

• Curl got good visibility. I presented on first day a session titled "RIA - Real Examples and Lessons Learnt", where four concrete customer examples were described, showing benefits of using Curl. Then Richard and I gave an interview to Sys-Con TV (not published yet). I also participated at a power panel yesterday on the subject "How are RIAs benefiting the bottom line?" You can see the other participants including last minute addition of Adobe (James Ward). Our simple booth was busy with many visitors getting a demo of Curl from the expert hands of Richard.

This AjaxWorld had several hundred people (my guess - 400), many did
not show up due to the harsh economic condition prevailing now.

(Cross posted from the Zuzu Curl blog)

Upon expanding the test cases for my tree classes in ZUZU.LIB.CONTAINERS, I discovered that in one degenerate case involving a pessimally balanced splay tree, attempting to serialize the tree using the default compiler-generated serialization routines resulted in a stack overflow. The problem was that I had a test case that accesses each element in the tree in order before attempting to clone the tree using serialization. For most self-balancing trees, this is not a problem, but for splay trees, this results in a tree that is as unbalanced as possible -- essentially just a long linked list. Because the compiler-generated object-serialize method recursively serializes the classes fields, serializing the tree nodes blows up the stack. This is a potential problem when serializing any linked data structure that may have arbitrarily large depth.

The way around this problem is to implement an explicit non-recursive object-serialize method and object-deserialize constructor for affected classes. The general algorithm is fairly simple:

1. Iterate non-recursively over the nodes in the datastructure. For each node, temporarily null out its pointers and serialize the node normally. The SerializeOutputStream will remember the objects and will not dump them out again if the same object is serialized later.
2. If the number of nodes was not known in advance, serialize out a sentinel value to delimit the end of the nodes.
3. Iterate over the nodes again in the same order and serialize the fields in order.

When deserializing, just reverse this process.

The following example demonstrates this problem for a simple linked list data structure. Note that in the linked list case the algorithm only requires a single
iteration because the next pointer is always just the next element to be serialized. To see the stack overflow, comment out the object-serialize and object-deserialize members.

Example

Note how I used the class version as an optimization to avoid serializing an extra null for each instance.

Fixing this for my tree classes was a little bit more complicated but the principle is the same. You can see my changes here.

(Cross posted from the Zuzu Curl blog.)

Frequently I find that I want to quickly sketch out the interface of a function or class method and compile it without actually implementing its body. If the function does not return any arguments, I can simply leave the body empty, but if it does return something, I might need to write a fake return statement to make the compiler happy. In either case, I usually want to leave myself a reminder that the code still needs to be implemented. In Curl, this can easily be done using an exception:

{define-proc {foo}:String
  {error "not implemented yet"}
}

The compiler knows that the 'error' function will always throw an exception and will therefore not complain that the function lacks a return statement. To create your own function like 'error', you only need to make a procedure that always throws an exception and that has a declared return type of 'never-returns':

{define-proc {unimplemented}:never-returns
  {error "not implemented yet"}
}

I have done one better than this by creating an 'unimplemented' syntax in the ZUZU.LIB.SYNTAX package that uses Curl's 'this-function' syntax to add the name of the unimplemented function to the error message. For example:

Run example

You can find the source of this macro here.

The ability to extend the syntax like this makes Curl a much more expressive language than most widely used languages today.