Ring in the new year with Songbird 0.4!

Ring in the new year with Songbird 0.4!
Us birders have been giving Santa’s hardworking elves a run for their cookies this holiday season, and we’re ready to release a final Songbird 0.4 for Developers just in time to ring in the new year.
Download it from the Songbird Developer Center.
It’s been less than 2 months since we released Songbird 0.3 and introduced our new open development platform, but we’ve built in a few new juicy tidbits that we couldn’t wait to get out. In particular, check out the following new features:
For more, check out the release notes.
Our new year’s resolution is to release early and often, so you can expect similarly quick cycles throughout 2008.
Happy New Year!
The Songbird Team
<!–
–>
Adium 1.2 beta!
The beta of Adium 1.2 is available. We’ve gone through several beta iterations already, and release shouldn’t be too far off. Please report thoroughly any regressions you find in your testing. Enjoy!
(Via Adium News.)
Organise Your Code With base2.Packages
Since Dean Edwards announced base2 beta he has been taking some time to describe it for us.
His latest installment is on base2 packages:
A base2.Package provides a mechanism for bundling classes, constants and functions within a closure. You can define what symbols you want to export from the Package and you can define the symbols you want to import into the closure.
The package concept is used throughout base2 itself to manage components and namespaces.
The template for creating a package is:
-
-
new function(_) { // create the closure
-
// create the package object
-
var MyPackage = new base2.Package(this, {
-
name: “MyPackage”,
-
version: “1.0″,
-
imports: “SomeOtherPackage”,
-
exports: “MY_CONSTANT,MyClass,myFunction”
-
});
-
-
// evaluate the imported namespace
-
eval(this.imports);
-
-
// define package contents
-
-
var MY_CONSTANT = 42;
-
-
var MyClass = SomeOtherClass.extend({
-
// class definition
-
});
-
-
function myFunction() {
-
return “Hello!”;
-
};
-
-
// evaluate the exported namespace (this initialises the Package)
-
eval(this.exports);
-
};
-
and here is an example that uses one:
-
-
new function(_) { // create the closure
-
// create the package object
-
var graphics = new base2.Package(this, {
-
name: “graphics”,
-
version: “1.0″,
-
imports: “shapes”,
-
exports: “Layout”
-
});
-
-
// evaluate the imported namespace
-
eval(this.imports);
-
-
// we can refer to the Rectangle class directly because we have imported the
-
// shapes Package.
-
var Layout = Rectangle.extend({
-
// I don’t know anything about graphics
-
});
-
-
// evaluate the exported namespace (this initialises the Package)
-
eval(this.exports);
-
};
-
(Via Ajaxian.)
WebKit gets Native getElementsByClassName
getElementsByClassName is one of the more common functions requested by JavaScript programmers (and added by JavaScript libraries); it works along the same lines as getElementsByTagName and getElementById in looking up elements of a web page by their properties. In fact, it’s so common that in the new in-progress HTML5 specification it’s been added to the official DOM API. Last week WebKit joined upcoming versions of Firefox and Opera in supporting this new feature.
The advantages of a native implementation are clear:
- No additional JavaScript library files required
- Clearly specified and consistent behavior
- Blindingly fast
How fast? Let’s have a look at WebKit’s shiny new implementation. For testing purposes I wrote a simple benchmark allowing comparison between three different methods for getting elements by their class names. The first is the new native getElementsByClassName, and the last two are both from prototype.js; one uses XPath, and the other is a straight JavaScript/DOM implementation.

The results speak for themselves. Web applications that do a lot of class lookups should see noticeable speed improvements when run with any of the native implementations, and existing JavaScript libraries can fill in for older or less advanced browsers. John Resig has run a different benchmark of the same functionality in Firefox 3 and observed a similar native vs. JavaScript/DOM speedup ratio.
Testing Methodology:
Tests were run three times, then averaged. The page was reloaded between each run. The browser used was Safari 3 with WebKit r28911. The hardware was a 2GHz Apple MacBook with 3GB of RAM running Mac OS X 10.5.1. The XPath and JS/DOM functions are from Prototype 1.5.1.
(Via Surfin’ Safari.)
CSS Text Wrap: Squeeze that text around any line
Sick of those straight lines that your text follows? Rounded corners can only do so much? Now, a new tool is here to help you out: CSS Text Wrap.
The CSS Text Wrapper allows you to easily make HTML text wrap in shapes other than just a rectangle. You can make text wrap around curves, zig-zags, or whatever you want. All you have to do is draw the left and right edges below and then copy the generated code to your website
On the flip side, you get a choice of inline HTML (below), XHTML with CSS classes, or JavaScript.
-
-
<div style=“float:left;clear:left;height:15px;width:4px”></div><div style=“float:right;clear:right;height:15px;width:3px”></div><div style=“float:left;clear:left;height:15px;width:13px”></div><div style=“float:right;clear:right;height:15px;width:8px”></div><div style=“float:left;clear:left;height:15px;width:22px”></div><div style=“float:right;clear:right;height:15px;width:14px”></div><div style=“float:left;clear:left;height:15px;width:30px”></div><div style=“float:right;clear:right;height:15px;width:19px”></div>
-
(Via Ajaxian.)
Announcing SunSpider 0.9
A New JavaScript Benchmark From the WebKit Team
Here in WebKit-land, we strive for great performance and we love to make things faster. When doing performance work, it’s critical to be able to measure how fast you are at any given time and track changes. And it’s important to make sure your metric reflects realistic use cases. None of the existing JavaScript benchmarks were exactly suited to our needs (more on that below), so we decided to make our own.
We’re widely announcing this benchmark today because we’d like to share with other browser-hosted and standalone JavaScript engines. And we’d like to have input from JavaScript experts on the usefulness and validity of the tests. In that spirit of cooperation, we’re not going to post competitive numbers or even comparisons to older Safari/WebKit versions for now (although I can tell you that the shipping version of Safari 3 is not the fastest JS engine we tested).
Try It Out!
But people like playing with these benchmarks. So I’m sure a lot of you would like to try your luck and test your browser. If you’d like to post your results in the comments, please mention what browser, what version, and what hardware and OS you’re running on. Make sure to quit extraneous apps and avoid jiggling your mouse for the minute or two that it runs. Have fun!
The Gory Details
There are a lot of JavaScript benchmarks out there already: Celtic Kane’s JavaScript speed test, the JavaScript processing test from iBench, Jason Orendorff’s JavaScript speed tests, John Resig’s tests, and others. But none of these were quite what we needed to measure improve real-world JavaScript performance.
So we made our own. Why bother? Well, we think our benchmark has a combination of useful properties that we didn’t see in any existing test:
- It’s based on real code that does interesting things; both things that the web apps of today are doing, and more advanced code of the sorts we can expect as web apps become more advanced. Very few of the tests could be classed as microbenchmarks.
- It’s balanced between different aspects of the JavaScript language — not dominated by just a small handful of different things. In fact, we collected test cases from all over the web, including from other benchmarks. But at the same time, we avoided DOM tests and stuck to the core JavaScript language itself.
- It’s super easy to run in the browser or from the command line, so you can test both pure engine performance, and the results you actually get in the browser.
- We included statistical analysis so you can see how stable the results you’re getting really are.
Incidentally, we’ve been doing a lot of work on JavaScript performance lately. If you’re interested in helping out, stop by the webkit-dev@webkit.org mailing list, or the #webkit IRC channel on chat.freenode.net and say hi. Our engine is highly hackable so it’s easier than you think to get started.
(Via Surfin’ Safari.)
YUI 2.4.1: Maintenance Release
In YUI 2.4.0, we updated the way the Event Utility “cleans up” events in its page unload handler. Regrettably, that change resulted in some events not being properly unloaded, which in turn resulted in IE-specific memory leaks in some YUI components (including the Menu Control and controls in the Container Family). Today’s release of YUI 2.4.1 rolls back that change; it introduces no further changes. All implementers on YUI 2.4.0 are encouraged to upgrade.
YUI 2.4.1 is available for download immediately.
(Via Yahoo! User Interface Blog.)
Java 6 Developer preview now available for Leopard
Merry Christmas Java developers – from Santa Steve! Java SE 6 Developer Preview 8 is now available for Leopard via the Apple Developer Connection. You need to be an ADC member to access this download, but registration for the basic online membership is free and provides access for the Java SE 6 preview.
As some of you may recall, in the immediate aftermath of Leopard’s release, Java developers were a little upset about the exclusion of Java 6 from the shipping release of Apple’s latest operating system. Until now, there has been little to no information about the Java 6 time line for Leopard, aside from some independent community-driven open-source projects.
This version Java SE 6 Developer Preview requires a 64-bit capable Intel-based Mac (a Core 2 Duo or Xeon) and Mac OS X v 10.5.1 or later. See the release notes (linked from the ADC download page – it requires a login so I’m not hotlinking from here) for more details.
Thanks Will!
Parallels vs. VMWare: Benchmark results
Like it or not, lots of us who own Intel-based Macs have to run Windows from time to time. Although Boot Camp is pretty fantastic if you need to run a processor intensive application (or you want to play games), virtualization is the more attractive solution for users who need to access productivity applications, like Microsoft Office 2007, but don’t want to have to live in the Windows environment. The two big players in the virtualization field are VMWare’s Fusion and Parallels’ Parallels. Both applications let you install a Windows XP or Vista virtual machine on your Intel Mac without having to leave OS X, both offer a level of integration between the two operating systems and both retai for $79.99 (USD). So, which virtualization program is the fastest? Well, that’s what MacTech attempted to find out in their exhaustive benchmarking trials, comparing Fusion 1.0 (build 51348), Parallels 3.0 (build 5160) and Boot Camp head-to-head-to-head in a variety of different computing tasks.
So what’s the bottom line? Because of how the software if designed to integrate between the two platforms, Parallels came out ahead in many of MacTech’s tests. For certain more processor heavy uses, VMWare, thanks to its ability to take advantage of both cores, came out the best. For networking performance, Boot Camp was king.
While I found the benchmarking tests very interesting – and useful – prospective buyers should be aware that in the middle of MacTech’s testing procedure, all three Windows options for OS X were upgraded. With the release of Leopard, Boot Camp came out of beta and VMWare is now at version 1.1 and Parallels was updated on December 5 to build 5582. I know just from my own unscientific experience, Fusion 1.1 improved significantly in speed and overall performance from version 1.0 and while I was a big fan of Parallels under Tiger, I have “switched” to Fusion for Leopard.
Trial-versions are available for both programs. Remember that in order to use Windows XP or Vista, you need a valid user license.
Thanks, Rich.
DWR: State of the Union
So DWR is now part of the Dojo Foundation. I thought it would be good to quickly summarize where we are, and what I’m working on, and to give everyone a chance to comment.
DWR 2.0 has been out for 6 months or so. At the time, I swore that the next release would be a small one, called 2.1. However it appears that I’m not good at swearing because there is lots in the next release – I think we’re going to have to call it 3.0.
Just as a quick recap, here’s what changed with 2.0:
- Reverse Ajax which I define as Comet or Polling or Piggyback, whichever works best.
- Spring Namespace support, Guice support, Annotations etc.
- etc. Every release needs some etc. See the release notes for more.
Since 2.0, we’ve been working on the following adding support for JSON, Bayeux, images/binary file upload/download, a Hub with JMS/OAA support and more reverse ajax APIs. I also want to get some Gears integration going.
There are also a whole set of non-functional things to consider:
- Moving the website to directwebremoting.org
- Restart chasing CLAs, using a foundation CLA rather than a Getahead CLA
- Get some lawyer to create a CLA so Getahead can grant rights to the Foundation (or something similar)
- Get someone to pony up and let us move to SVN
- Unit tests
JSON support: One goal is a RESTian API so you can do something like this: http://example.com/dwr/json/ClassName/methodName/param1/param2 and DWR will reply with a JSON structure containing the result of calling className.methodName(“param1″, “param2″); It would be good to support JSONP along with this. We might also allow POSTing of JSON structures, although I’m less convinced about this because it quickly gets DWR specific, and then what’s the point of a standard. Status – DWR has always used a superset of JSON that I like to call JavaScript. We do this to cope with recursive data, XML objects, and such like. I’ve done most of the work so that DWR can use the JSON subset, but not created the ‘handler’ to interface between the web and a JSON data structure.
Bayeux Support: Greg Wilkins (Jetty) committed some changes to DWR, which need some tweaks to get working properly. Greg still intends to complete this.
File/Image Upload and Download: This allows a Java method to return an AWT BufferedImage and have that image turn up in the page, or to take or return an InputStream and have that populated from a file upload or offered as a file download. I’ve had some bug reports that it doesn’t work with some browsers, also we need to find a way to report progress to a web page simply. See this post on Ajaxian for more.
DWR Hub and integration with JMS and OpenAjax Hub: We have a hub, along with one way integration with JMS. The OpenAjax portion will be simple except for the getting the OpenAjax Hub to work smoothly with JMS part.
Reverse Ajax Proxy API Generator: The goal with this is a program that will take JavaScript as input, and output a Java API which, when called, generates JavaScript to send to a browser. Some of this work has been tricky, but then meta-meta-programming was always bound to be hard. This currently mostly works with TIBCO GI, but more work will be needed to allow it to extract type information from other APIs. I hope we will be able to create some Dojo integration for 3.0 too.
DOM Manipulation Library: Currently this is limited to window.alert, mostly because I’m not sure how far to take it. There are a set of things like history, location, close, confirm that could be useful from a server, and that are not typically abstracted by libraries.
Gears Integration: I’ve not started this, but it needs to take higher priority than it currently does. It would be very cool if DWR would transparently detect Gears, and then allow some form of guaranteed delivery including resending of messages if the network disappears for a while.
Website: We need to get the DWR website moved away from the Getahead server, and onto Foundation servers. There will be some URLs to alter as part of this, and I don’t want to lose Google juice by doing it badly.
The documentation for DWR 2 was not up to the standards of 1.x, and while it has been getting better, we could still do more. One thing that has held this back has been lack of a DWR wiki. I hope we can fix this with the server move.
Source Repo: We are currently using CVS hosted by java.net. They support SVN, but want to charge us a few hundred dollars to upgrade. I expect to move away from collab.net/java.net CVS some time early next year.
Unit Tests: I’ve been trying for ages to find a way to automatically test with multiple browsers and servers. WebDriver looked good for a while, but it doesn’t look like the project is going anywhere particularly quickly, so I’m back trying to get Selenium to act in a sane way.
Etc: There’s always ‘other stuff’. I’ve particularly not gone into things like Grizzly support. There’s plenty of etc in this release too.
(Via Joe Walker’s Blog.)


leave a comment