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).