Firebug 1.2 beta for Firefox 3 RC 1

Firebug 1.2 beta is in the wild. The latest beta of the bug your FF3RC will love features:
Enablement UI
- Disable always: when the Firebug UI is not active on any page, the debugger is disabled (minimal overhead)
- Instant on: when the Firebug UI is active, HTML, CSS, DOM views activate (minimal overhead)
- Script panel user-activation: initially disabled or enabled always
- Net panel user-activiation: initially disabled or enabled always
- Bug Icon gray unless some page has Script or Net panel activation
- No Allowed-sites/Disable for Site: no longer needed. The UI for this feature is being refined; overhead tests have not been completed. We are interested in feedback on this UI change.
- Javascript Debugging
- Written/cleaned up eval support
- Performance on eval better, easier to support. This feature is complete; Bug reports on javascript debugger welcome.
- Net Panel
- Net timing more accurate
- Only real network requests displayed.
- Limit for number of requests (configurable in preferences).
- Additional columns for: request method, status response + text
- Cache tab has expiration time in Net panel
- Console
- Redesigned to use events/attribute passing.
tests/console/joes-original/test.html mostly passes
- Command Line
- Redesigned to avoid using evalInSandbox.
tests/console/commandLineObjects.html mostly passes
commandLineAPI functions, ok.
- DOM Panel
- Works for FF3pre after about 2008041406 (https://bugzilla.mozilla.org/show_bug.cgi?id=425139)
Bug away!
Time to overcome Java misconceptions

Program, profile, repeat
Myths and legends It doesn't really matter which version of the Java platform you use, does it? Well I know for sure that thread context switching is expensive. Isn't it? OK, but there's no doubt that 32-bit Java Virtual Machines (JVMs) are faster than 64-bit JVMs. Right?…
Google’s New Maps API for Flash

Last week, Google announced the Google Maps API for Flash, the latest extension of their extremely popular Google Maps API. As they describe:
This API lets Flex developers embed Google Maps in Flash applications. Similar to the JavaScript version, this ActionScript API provides a number of utilities for manipulating and adding content to maps through a variety of services, enabling you to embed robust, interactive maps applications on your website.
You can get a sense of the new level of interaction via their Photo Flip Map example (mashup profile):
An obvious question is: How does the Flash API compare to the JavaScript API? We get a partial answer from Mike Jone’s post announcing the API:
So, what do I like about the API for Flash? Smoothness and speed are a big part of it. We’ve designed it so that Flash graphics can be used for each tile layer, marker and info window - opening up possibilities like dynamic shading, shadowing, animation, and video. When the user zooms the map, magnification changes happen smoothly and place names fade in. After the user drags a marker, it gently bounces to a halt. Generally, Flash allows for much greater embellishment, and, well… “flashiness.” I get excited just thinking about the creative ways developers might take advantage of having a Flash API for Google Maps.
To learn more about the Google Maps Flash API, you can study some example demos and code samples, in addition to working through the tutorial. It will also be interesting to compare the Google Maps API for Flash with the Yahoo! Maps API , which has had a Flash APIs for some time now.
We’ve added a new Google Maps Flash API profile and for more coverage of this launch see:
- Google Maps Coming to Media, AIR Desktops, via Flash API - ReadWriteWeb, from whose discussion thread we can learn that AIR is not currently supported in the Google Maps Flash API
- Tutorial : Thematic mapping with the Google Maps Flash API
Ahead of Rootkit Talk, Cisco Patches Router Flaw
(PC World)

Google Sites now open to everyone

A few months ago we launched Google Sites exclusively as part of Google Apps for companies and organizations that wanted to use the service on their own domains. Now we've made it easy for anyone to set up a website to share all types of information -- team projects, company intranets, community groups, classrooms, clubs, family updates, you name it -- in one place, for a few people, a group or the world. You can securely host your own website at http://sites.google.com/[your-website] and add as many pages as you like for free.
Getting started with Google Sites is easy. You can create different types of pages from scratch with the click of a button, and you can embed documents, calendars, photos, videos and gadgets directly into those pages. Similar to Google Docs, built-in editing tools allow for popular text and formatting changes to be made in a straightforward, WYSIWYG manner. Once your site is up and running, inviting people to edit or view your content is as simple as entering in their email address (of course, you can change access levels at any time). And you (or anyone who has editing privileges) can add or edit information whenever you'd like.
Here's a quick look:
Stay up to date with the latest news on our new Google Sites blog.
Latest Red Hat Enterprise Linux released

Red Hat is on top of the business Linux world and it has no intentions of coming down. Its newest release of Red Hat Enterprise Linux (RHEL), version 5.2, is designed to make sure that it stays on top.
Next Office 2007 service pack will include ODF, PDF support options

OpenID: A Contrarian View

We’ve offered you plenty of coverage of OpenID here at WWD: from early coverage when OpenID was in its infancy, through a look at the balance between providers and consumers, to dutifully mentioning when sites that we cover support OpenID. And yet, despite these various deep dives and having tried several OpenID providers myself, I have to confess: I just don’t use OpenID. Beyond that, it’s starting to look like a bad solution to a marginal problem to me.
It’s worth pointing out that this attitude puts me out of step with some of my technological peers and WWD readers. Indeed, what got me started thinking about OpenID again was the appearance of the Demand OpenID site, where (at the moment), 422 people are demanding OpenID from 673 web sites. The site was inspired in part by a WWD reader who couldn’t use OpenID to comment here, and two of you readers are demanding it here. (Just to be clear, WWD does not have an official stance on OpenID, although we’re currently unlikely to switch to an OpenID-enabled site).So what’s my beef with OpenID? It’s threefold: I don’t need it, I can’t use it, and I don’t trust it.
I don’t need it: Like the majority of readers who’ve commented to us about identity management, there are already good solid solutions for managing logins across a multitude of web sites. I’m currently using 1Password; others depend on RoboForm or the built-in password management functions in their browsers, among other choices. WIth 1Password I can create as many unique logins and strong passwords as I like, and though there is still a single point of failure, it’s a point of failure under my control; I can take measures I consider appropriate to protect my computers and software. With OpenID, if there’s a compromise there’s not much I can do to protect myself across the web of sites where I’ve used it.
I can’t use it: Like the folks behind “Demand OpenID,” I’m finding plenty of sites that I use on a daily basis that don’t support OpenID. Demand as I might, I need to be able to log on to those sites today; thus I have to have a password-management solution in place. If I’m going to need to manage passwords anyhow, why not do that for every site I visit? I’m aware that this is a chicken-and-egg problem, but so far there are no sites that are requiring me to use OpenID instead of a traditional login; until there are, there’s no compelling reason to move me in that direction.
I don’t trust it: This has been discussedextensivelyelsewhere, and there’s been more heat than light thrown on the issues. But my own personal take is that at least some OpenID implementations make it frighteningly easy for malicious sites to steal your credentials. There are providers working to prevent this - Verisign and Vidoop are two of them - but the average naive user won’t know enough to look for a secure provider. Given that I believe widespread OpenID adoption would make it an attractive target for phishers, and that the average user will not use it securely, I am loathe to encourage its adoption.
I realize there are people for whom OpenID is a good solution: many of them are in the always-on-the-go, never-use-the-same-computer-twice group of cutting edge hyperconnected web workers who are smart enough to avoid the security pitfalls. But I believe the bulk of users, even the bulk of web workers, don’t fall into this category. If you spend most of your time on a single device, and are adequately happy with your current login and password authentication, then there’s no need to push your identity management out to the cloud.

