Embed This!

You may have heard the changes afoot in ECMAScript and the proposed successor versions to the current ECMA-262 standard. After a couple of years slaving over a new revision called ES4 and much infighting, the ECMA TC399 group has announced a significant change of strategy. The previous ES4 proposal is no more and in its place, is a yet to be defined new direction called “ES-Harmony“. The previously fighting factions are unified, but at a loss of the driving force of Adobe. Funny, that you need quite a bit of disharmony to get Harmony. Read Brendan Eich’s thoughts.

Adobe had provided much of the initial design impetus for ES4 by contributing the Tamarin VM and much of the ActionScript language design into ES4. So to lose Adobe’s energy and ideas will be a big loss. Sure adobe will continue to be involved, (read the Official Line), but don’t expect them to drive the new direction. I expect that ActionScript will continue to adopt many of the good things from the ES4 design and to track ES-Harmony when it delivers. As a result, ActionScript will get stronger not weaker. Freed from the burden of a committee standards process, they will certainly deliver sooner rather than later.

Ejscript and ES-Harmony
How does this all relate to our Ejscript which is an implementation of Javascript for non-browser use (think Mobile, Server side web frameworks and embedded). Well, Ejscript is one of the most advanced implementations of ES4 and already includes most of the big advances of ES4. It supports classes, interfaces, modules, namespaces, early binding, optional type annotations and many of the smaller proposals in ES4. It is a very sweet language to use. However, ES4 is no more and ES-Harmony is quite a way off into the future, so Ejscript will continue to innovate and explore creative improvements to Javascript. We will track “ES-Harmony” and adopt proposals as they become firm. But our focus will be on delivering real technology and making Ejscript the best non-browser implementation of the future of Javascript.

In the meantime, Ejscript is the way to explore the new directions of Javascript today.

We’ve just posted the www.ejscript.org web site to be the home of the Ejscript lanaguage.

Ejscript is an enhanced implementation of the Javascript language intended for use outside browsers. Early versions of Ejscript have been embedded via Appweb in millions of devices. It is also being used in Samba 4. But now, the new version takes the language to a new level.

We’re supporting most of ECMA-262, and lot from the proposed ECMAscript ES4/Harmony. Still quite a way to go to add support for prototype inheritance, Unicode 16/24 and many other features. But the current preview release should be a good start.

Although a lot of foundational work on Appweb 3.0 has been done in the last year, real coding has now started in earnest.

The 3.0 release is going to be a major break from the 2.4 branch and so we will continue to maintain 2.X through 2008. The reason for this dual version strategy is that 3.0 is going to have to modify quite a few APIs.

Our design goals for Appweb 3.0 are:

• Greatly enhance the ESP / EJScript environment
• Tighten the Appweb core to be even more robust, smaller and faster
• Improve the “out-of-box” or getting started experience

Appweb 3.0 will have the following core features:

• Support EJScript 3.0 which supports the emerging ECMA-4 standard for Javascript. EJScript 3.0 is a Virtual Machine based design which should be 10-50x faster and have the latest language features.
• Upgraded ESP support for templating, and a library of pre-supplied user controls
• The Appweb core now is written in C instead of C++. The C++ APIs are supported via a loadable module for backwards compatibility. However, access to the core internal data structures will by necessity change
• New input and output pipeline. All modules can now have output filtered and chunked
• Improved event based runtime for higher performance
• Fast CGI support
• Watchdog to restart the server incase of crashes

The EJScript 3.0 language is the biggest feature. This will provide a language environment when used with ESP that is (in my humble opinion) superior to PHP but at a fraction of the memory footprint. The new EJScript has: classes, interfaces, objects, integrated XML support, bound closures, optionally typed variables, packages and namespaces plus a lot more.

Anyway, that is all for now — back to coding!

When I first purchased my MacBook Pro, I was generally very happy with its performance, but it was hot, very hot. But with Leopard, it runs not so hot, in fact, it is pleasantly cool.

Before Leopard, I learned to sit with the MacBook balanced with the outer edges on my legs so I would not have to touch the underside which was sometimes too hot to touch. Other times, I’d put a large book underneath to insulate my legs. Even when on a desk, it ran very hot.

Now I acknowledge that I am a power user. I do software development, run many apps and have 4 GB of RAM. But this was definitely the hottest notebook of any brand I’ve ever used. I had started to resort to closing any app that was using CPU cycles to try to cool the note book down. I ran Activity Monitor and killed Skype, Firefox and any background apps that seem to constantly use 2-4% of the CPU each. But the system still ran hot. Until …

A week ago, I upgraded to Leopard. The upgrade, I might say went pretty smoothly. Features like spaces and time machine were the hooks that lured me to upgrade early. But there is a hidden benefit for MacBook Pro users, maybe for all Mac users. Leopard seems to manage the CPU better so the entire system runs significantly cooler

I’ve not done any quantitative tests or measurements, other than the subjective test of “Can I use it normally as a laptop would be used - on your lap”. My guess is that Apple did some tweaks to put the Intel CPUs into a deeper, longer sleep cycle and thus conserve power and lower core temperatures. Perhaps Apple could comment?

I can’t guarantee that all will experience the “no so hot” Leopard, but if your MacBook runs too hot — it is worth a try.

Running cool!

I’ve been working quietly for a while on a new implementation of Javascript / ECMA Script. This work started after the success using Javascript as a server side language for embedded web servers, in particular our Appweb embedded web server and before that the GoAhead web server.

But this time round, we’re doing it with an entirely new code base and technical foundation.We’re tracking the new and evolving ECMA Script 4 (ES4) standard. This is a very cool evolution of the current Javascript language used in web browsers. It takes the core language, preserves backward compatibility so that old web pages continue to run, but it adds a suite of new features culled from the very best learning in language design from the past 10 years.

My interest is implementing ES4 in embedded and mobile devices. So our implementation will be somewhat different to that of web browsers. Our implementation must run with minimal resources on modest CPUs. We don’t have the luxury of multi-megabytes and multi-core CPUs. A few words about our design:

• Dual license open source GPL and commercial licenses
• VM implementations in C and Java including J2ME
• Optional stand-alone compiler to pre-compile scripts into byte code files

I’ll blog more about this as we go and as we get closer to releasing source. Questions welcome …