With the release of Sedona this summer, Tridium has entered a whole new realm. Previously all of our software technology was based on Java, which meant it could only be applied with fairly hefty hardware solutions. But with Sedona we now have software technology which can scale down to edge devices and smart sensors. Parallel to scaling down our software technology, Tridium has become quite involved in what it takes to scale the Internet down to edge devices. The first step of this effort is Sedona's use of 6LoWPAN, but the end-game is the "Web of Things". I have detailed our vision for the Web of Things in a new whitepaper. I would encourage you to give it a read and help us make this vision come true!

I just stumbled across an old video from 1995 on the Self programming language. Most people have probably never heard of Self - it is a rather obscure language from the 90s. But Self is probably the biggest source of inspiration for many of the key design concepts found in both Niagara AX and oBIX.

I'm excited to announce that Sedona now includes support to run on the Java VM. You might ask yourself why would I want to run Sedona on the JVM? There are two key reasons to run on the JVM:

Anybody who has heard our Sedona story, has also heard the 6LoWPAN story. AutomatedBuildings is running a great article about 6LoWPAN, which you should check out if you haven't seen it.

As a true open source project, one of the things we'll be doing in the next few months is creating a public version control database for the Sedona codebase (just the actual open source part that is mind you). This means that everyone will have public access to the "live" source code repository. Instead of waiting for a Sedona build to get your changes, they will be available immediately as soon as they are checked in.

In Java all methods are virtual by default unless explicitly marked as "final". Personally I think this was a poor design choice. You must explicitly design for a class and a subset of its methods to be overridden or else your APIs are highly unlikely to be future proof. The C# language got it right and requires virtual methods to be marked with the "virtual" and "override" keyword.

Yesterday one of the highest US federal courts overturned a lower court's decision regarding how open source licenses work. For anyone using open source licenses this is a really, really big deal.

A compiler is basically a program used to translate another program from one format into another format. For example a C compiler translates C source code into machine code. Javac compiles Java source code into Java bytecode. Sedonac is actually a suite of compilers - the most interesting one is compileKit which translates Sedona source code into a kit file containing IR (intermediate representation).

We've had an open source, client side toolkit for a few years now available at SourceForge. Now there is some activity to start a new open source project for building an oBIX server toolkit. If you have any interest in contributing ideas, feedback, code, or just want to keep abreast of things, then please join the oBIX Developers on Google Groups.

We're gearing up to start work on oBIX 1.1. Right now we're looking to add two new features to oBIX. The first is to specify how oBIX is used with RSS and Atom for feeds. The second feature were looking at is scheduling support within oBIX - most likely based on the iCAL standard (for example can I email the building control system from Outlook).

We build software systems to solve real world problems: control the temperature in a building; monitor energy usage; let our customers buy things online. All of these systems end up "modeling" their domain. In building automation we model environmental conditions and equipment; for energy applications we model meters, weather forecasts, and rate pricing; online stores model products, shopping carts, and invoices.

Someone asked me the other day why we don't annotate slots as inputs or outputs. If you remember back in the good old r2 days we actually did this - and it turns out to be immensely limiting, without much practical value. Basically any slot (or data item) should be a potential output - if you can read it, then you should be able to use it as the source of a programmatic link. Furthermore, anything you can change on the property sheet ought to be changeable programatically via a link. So the only thing that really matters is should a property be changed externally (either via a property sheet or a link).

Back in the good old Java 1.0 days the JDK was less than a dozen packages. The original Javadoc sported the latest 1995 HTML look & feel with its rainbow of colored bullets (everybody who was cool used colored bullets back then). Java 1.1 added a couple of new packages - some were killer new features like java.reflect and java.util.zip.

It's been a long time since I've blogged on Sedona (well actually it has been a long time since I blogged about anything). That's because I've been busy hacking away at a new Sedona compiler. About a month ago we decided our current design for Sedona was wrong. Writing Sedona components in Java, then compiling them into C++ had a couple big problems:

We have an annual series here called the Richmond Forum that brings in big name speakers each month - usually they are pretty good. This past weekend the speakers were "futurists" Alvin Toffler (author of Future Shock) and Malcolm Gladwell (author of Blink). Gladwell is a great speaker - he discussed how problems today have shifted from "puzzles" to "mysteries". A puzzle is basically a problem of collecting information, whereas a mystery is a problem of trying to make sense of the information you already have. To quote an example from his article in the New Yorker: