If like me your head is spinning from all the announcements of proprietary "AJAX killers" out there then you probably were still too busy trying to digest Silverlight to even have heard that Sun's announced it's own "AJAX killer" and Flash competitor named Java FX.

Don Park has a good post which serves as a good starting point to grok the meat of this announcement titled Inside JavaFX where he writes

So what is JavaFX? This is what it looks like:

import javafx.ui.*;

Frame {
  title: "Hello World JavaFX"
  width: 20
  height: 50
  content: Label {
    text: "Hello World"
  }
  visible: true
}

As you can see, JavaFX script (*.fx) is basically JSON-like version of XAML which can be either compiled into Java bytecode or run as is using a java-based JavaFX player. Since JavaFX is just java, it can run as applets in browsers, midlets on mobiles, and applications on WebStart.

Sam Ruby has a good follow up to Don's post titled JavaFX Script where he describes some of the innovations and shortcomings of the platform he has noticed in his initial observations.

It looks like Web developers are getting spoiled for choice this summer; Sun vs. Microsoft vs. Adobe vs. Web Standards.

From the announcement on the Gamerscore blog entitled Windows Live Messenger Comes to Xbox LIVE, Uniting Friends and Families on the TV, PC and Mobile Phone we learn

Beginning May 9th, Xbox LIVE, the most interactive gaming and social network available, is once again expanding with the arrival of Windows Live Messenger on Xbox 360. This new feature, available as part of the Xbox 360 Spring Update, will connect people across Xbox 360 consoles, Windows PCs and Windows Mobile devices. Xbox LIVE members will be able to socialize with people on their unified friends list, including their contacts from the more than 260 million Windows Live Messengers across the world. With Instant Messenger, Xbox LIVE members will have the ability to:

• Chat via instant messenger with up to 20 contacts in a single conversation, and have up to six different conversations at the same time with people on PCs, mobile phones and other Xbox 360 consoles.
• Instant message while playing games, listening to music or watching movies or TV shows downloaded from Xbox LIVE Marketplace.
• View at a glance if friends on Windows Live Messenger have gamertags and add them to a unified friends list.

Folks on my team have been working on this integration for a while and I was even roped in a couple of times. I'm glad to see it finally in the hands of our users. This is a nice bit of synergy from Windows Live and XBox Live.

After I blogged about this announcement the first time around, Andrew who is both an XBox Live and Windows Live messenger user voiced some privacy concerns in his post One of my Many Irrational fears... where he wrote

My problem with the new Spring update for the XBox 360 lies in the Windows Live Messenger integration. It's been commented elsewhere that your contacts will be able to see what games you're playing, your gamertag, etc.

Well I have people, parent, family, whatever that I do not want seeing what I am playing at any one point in the day - this is why I didn't enable the ability to show what I was listening to on my Windows Media Player when that became available.

In fact, I quite like the thought that I can do whatever the hell I want in my leisure time without everyone being notified of it.
...
In fact you will find a comment from me regarding my displeasure on this on Dare's blog (no response), I did post it to Ozymandias' blog (disappeared), and Gamerscoreblog (no response).

These are three of the more accessible blogs from people who are involved in this decision and none of them has decided it was worth responding to my questions. Specifically I do ask if there will be an opt out - something that the Live Messenger team gave people in regards to Windows Spaces - as Dare mentioned.

Andrew has raised a valid concern and immediately after I saw his post I talked to the PM who worked on the feature to see if there was a way to opt out of the feature. I got the answer and I've been waiting until the Spring XBox Live update was out before talking about it in detail. Now that it is out, I can address how to opt out of this feature if you have privacy concerns about it: 

The feature is enabled by default once you opt-in to link your .NET Passport account/Windows Live ID with your XBox Live account. To disable the feature after you have linked your IDs, you need to turn off the option to automatically sign-in to Messenger when logged into XBox Live. The steps to do this from XBox Live are

1. click on profile
2. click on 'auto sign in'
3. there is an xbox and a messenger section. Click disable on the messenger option

Voila, and that's it. Your leisure time privacy is preserved.

In recent months it has become clear to me that the largest Web companies have become quite serious about providing "web platforms"that Web developers can integrate with or build upon. Amazon (http://aws.amazon.com), Google (http://code.google.com), Yahoo (http://developer.yahoo.com) and Microsoft (http://dev.live.com) all provide online destinations where Web developers can learn how to use their Web services or integrate with their AJAX widget platforms. The problem with building a platform is that providing Web services and writing APIs is the easy part. The hard part is hard work of supporting developers who have built on your platform with proper documentation, prompt tech support, and ensuring backwards compatibility when new revisions of the platform are delivered. Today I feel like riffing on that last point; versioning and backwards compatibility.

Maintaining backwards compatibility and being mindful of forwards compatibility is one of the biggest design problems that faces platform vendors. So far, there have been numerous examples of Web companies that provide APIs failing to realize how important stability and backwards compatibility when providing a platform. I've seen numerous examples of breaking changes in APIs providing by Web companies including the Google Adwords API (shutting down old endpoints with new version), TypePad Atom feeds (switching the feed format to a new incompatible version thus breaking feed readers), del.icio.us API (changing the Web service URL and the security protocol) and Amazon Web Services (changing what is added to a shopping cart when an item is added via its Amazon specific ID) among many others. Some of these changes were necessary due to security concerns while others could have been prevented with better up front design and decision making by the platform vendor. However in all of these cases, developers that had taken a bet on the platform had to scramble to check that their applications still worked and patch/redistribute them if they didn't. That is bad. One of the primary goals of a platform vendor is to ensure that the lives of developers on their platform is as easy and smooth as possible. This means releasing a new version of the platform should not cause developers who have taken a bet on the platform to have to rewrite their code.  

In the past I've written lengthy, and fairly complex articles about versioning and XML data formats. These days, I've boiled down my guidance on Web service versioning to one phrase; Cool URIs Don't Change. This simple philosophy is actually all you need to consider when designing your RESTful Web service. You apply it in the following way

1. The Web service end point (i.e. URL) should not change. Changing the actual service end point is bad (e.g. http://del.icio.us/api/posts/get to https://api.del.icio.us/v1/posts/get) instead you should design your URI space with the knowledge that there will be multiple versions of the protocol.
   
2. The types of messages returned by the end point should not change. Thus changing the data format of the service (e.g. changing from RSS to Atom or Atom 0.3 to Atom 1.0) is a bad idea. Thus you should have a strategy for supporting multiple formats and partition your URI space accordingly.
   
3. The behavior of the end point should not change. This is the trickiest one to follow but the one that your developers will appreciate the most. New versions of the API should not change the behavior of operations previously defined at that end point. One way to reach this ideal is to partition your URI space in a versioned manner (e.g. http://www.example.com/api/v1/get-stuff in version 1 and  http://www.example.com/api/v2/get-stuff in version 2) and then never change the behavior of the old bits or at the very least keep that behavior around as long as possible.
   

That's it. That's all you really need to know about versioning and REST Web services. The rest is mainly finicky details that are primarily dependent on the specifics of the platform  and the ease with which the developers on the platform can respond to breaking changes. The harder it is for them to change, the higher the bar should be for breaking changes. For example, for Windows Live Messenger we have a high bar for breaking changes in the protocol that the server uses to talk to the desktop client because we know for a fact that not only does it take a surprisingly long time for the majority of users to switch to a new version of the client, there are users who actually cannot upgrade for a variety of reasons (e.g. new versions of desktop client doesn't work on their OS, corporate users or students who can't install software on the PC without permission, etc). On the other hand, when it comes to the internal SOAP APIs that are used to communicate between the Contacts platform and Windows Live properties such as Windows Live Spaces, Windows Live Hotmail and so on the bar for breaking changes is slightly lower because (i) they are Web applications and the (ii) set of consumers of the API is limited.

Ensuring that a Web platform has a strategy for handling backwards compatibility issues is just as important in the Web 2.0 world as it is on the desktop. Platform vendors who think otherwise are in for a rude awakening if they want adoption of their Web platform by serious developers.

It's been a while since I've written about RSS Bandit. In fact, I haven't written anything since we released v1.5.0.10 formerly codenamed Jubilee about two months ago. Between getting my work affairs in order to so I could travel to Nigeria, spending a few weeks there and then coming back to catch up on work, I haven't had much time for RSS Bandit. However I can now see the light at the end of the tunnel and will be able to start writing code again by this weekend.

Since we shipped the release, there have been two major issues reported which Torsten has been working on. In his post RSS Bandit and the 100% CPU issue the issue of the application using 100% CPU is addressed thusly 

Today I could track down an annoying issue: on some installations of the newer version of RSS Bandit (starting with the first betas of 1.5.0.x) it starts using 100%CPU time on a thread. As we started also to use lucene.NET with this new release I guessed it was a related issue, I was right. But as we run into multiple issues with lucene it was not obvious as a separate problem. So here it is:

We used a slightly modified version of lucene.NET to include the available language dependent analyzers and stopword filters. Before we released, I already fixed some obvious issues I got with e.g. french stemmer. Now we got more with the CJK (Japanese/Korean, bug report) and possibly Chinese analyzers. It looks like it get into a state it never returns. The attached debug callstack was very helpful to got the direction to search for! I found this: TextReader.Read(char[], int, int) was called and the return value checked against -1 only, not against 0 (zero). So I run over all analyzers to find all the places I have to change that code and here it is: the modified lucene.net.dll (zipped, 142K).

A number of users have grabbed the linked DLL and followed Torsten's instructions and fixed the problem. The second issue and solution can be found in the RSS Bandit forum post Beta Bugfix debugging version 1.5.0.12 where Torsten writes

All of you reporting/considering the lucene related indexing errors, please download and try the Beta Bugfix debugging version 1.5.0.12 from http://rssbandit.sourceforge.net/builds/RssBandit.1.5.0.12.CVS.bin.zip

Report any further issues related to lucene only as responses here (with the usual infos as OS and version etc.).

Thanks!

PS: you should delete the whole folder named "index" in the RSS Bandit user data folder before starting the application, the old index is possibly corrupted because of the errors before.

A number of users have reported getting exception messages related to the Lucene search index and this is due to threading issues we are facing while manipulating the search index. I thought I had handled all the issues in the final release but it seems I was mistaken. If you are an RSS Bandit user who has faced some of these issues, try out the version of the application fix linked above and let us know if the problem goes away.

Both of these fixes will be in an upcoming release of RSS Bandit that will ship at the end of the month. I may add a tiny feature with this bug fix release; adding pagination to newspaper views which is something I've wanted to do for at least a year now.

From the Microsoft press release Microsoft Launches Windows Live Hotmail Worldwide we learn

REDMOND, Wash. — May 6, 2007 — Microsoft Corp. today announced that Windows Live™ Hotmail^®, the successor to MSN^®
...
As Windows Live Hotmail begins rolling out on May 7 and continues over the coming days, consumers will be able to visit http://www.hotmail.com to sign up for a new Windows Live Hotmail account. Current MSN Hotmail customers can also update their existing account to Windows Live Hotmail by logging into their account and clicking on the green Join Windows Live Hotmail button.
...
Hotmail, is launching globally in 36 languages. The most significant upgrade for Hotmail since it pioneered the webmail industry in 1996,

• Outlook Connector. Available later this month in 11 languages worldwide, the new Microsoft Office Outlook Connector beta will enable people to view and manage their Windows Live Hotmail account from Outlook for free, with full contact, e-mail and e-mail folder synchronization.

Congrats to Omar Shahine, Reeves Little and the rest of the Hotmail crew for getting this release out the door. This has represented man-years of work from the team and lots of us across Windows Live. Also, free access to Hotmail for Outlook users has been long overdue. I'm glad we've finally given this feature to our users. Kudos all around.

You can read more about the release from Omar in his post And We've Shipped and from the Windows Live Hotmail team's blog post It's Here and the Fun Has Only Just Begun

PS: Liveside has some news about the other Windows Live mail product in their post Windows Live Hotmail launches; "Windows Live Mail" to succeed Outlook Express and Windows Mail

By now most people interested in technology news have heard the story initially reported by the New York Post in the article Bill's Hard Drive which claimed that Microsoft was planning to purchase Yahoo! and the subsequent rebuttal of this news in the Wall Street Journal's article Microsoft, Yahoo Discussed Deal. Since I work at Microsoft I'm not supposed to comment on rumors like this so I'll just point to a couple of opinions.

Charlene Li, an analyst at Forrester Research, wrote in her blog post entitled Why Microsoft + Yahoo! makes sense – and why it won’t work that

But there is one major reason why I don’t think Microsoft executives have the stomach for any sort of brand rationalization -- the continued dual branding of Windows Live and MSN. Each time I have a conversation with Microsoft about Windows Live, I get a different explanation of what it is and how it fits with MSN. If the company can’t event figure out its branding strategy with existing properties, I don’t hold out much faith that they could do so with a premium brand like Yahoo!

Robert Scoble writes in his post No “Microhoo”

I’ll tell ya one thing, though. It sure made for interesting conversation with a Yahoo employee I met tonight. We were starting to draw up where value would be built and where it’d be destroyed. There were a lot of places it would be destroyed and if two guys drinking beer can figure that out in half an hour, I’m sure that caused smarter people than us to put on the brakes. For instance one of Yahoo’s biggest properties is its email service. But that’s one of Microsoft’s biggest properties too (aka Hotmail). Then you look at finance sites. Microsoft is doing pretty well there with Microsoft Money (I met an employee who works there too and he said both Microsoft and Yahoo are way ahead of Google in finance traffic). Then you look at mapping. Again, they are pretty strong competitors there. Search? Who’s search technology would be thrown away? Advertising technology? Both Microsoft and Yahoo are pretty close there. Flickr? Clear value creation in an acquisition cause Microsoft doesn’t have anything like it. Same with Del.icio.us, Upcoming.org, Yahoo Answers, MyBlogLog. Portal? Yahoo is clear winner in brand name, but that’s just cause Microsoft has done an awful job in rebranding everything as “Live.”

As for me, two phrases popped into my head when I heard the rumor; hail mary play and post merger layoffs. I guess word association is mother...

In related news, Mike Arrington reported yesterday that Yahoo To Shut Down Yahoo Photos In Favor Of Flickr. This is a shockingly disruptive move that will definitely piss off users given how different the features and target audience of both sites are. Why would a Web savvy, user-centric company like Yahoo! do something that will so obviously cause bad blood between them and their users? How about all the employees working on Yahoo! Photos who busted their butts to make it one of the Web's most popular photo sites? The answer is simple. Yahoo! has redundant and competing products which they could no longer rationalize.

Now go back and reread Robert Scoble's post linked above then consider what a YHOO-MSFT merger would look like again.  

Have you been trying to distill the recent Microsoft Silverlight announcement into actual concrete bits and pieces? Look no further than this poster which not only lists the various supported browsers and operating systems but also highlights which class libraries from the .NET Framework will make up Silverlight

PS: Found this via Mark Pilgrim's Silly Season post. As usual, excellent and insightful writing by Mark.

Andy Conrad, who I used to work with back on the XML team, has two blog posts about Project Astoria and Project Jasper from Microsoft's Data Programmability team. Both projects are listed as data access incubation projects on MSDN. Below are the descriptions of the projects

Project Codename “Astoria”
The goal of Microsoft Codename Astoria is to enable applications to expose data as a data service that can be consumed by web clients within a corporate network and across the internet. The data service is reachable over regular HTTP requests, and standard HTTP verbs such as GET, POST, PUT and DELETE are used to perform operations against the service. The payload format for the service is controllable by the application, but all options are simple, open formats such as plan XML and JSON. Web-friendly technologies make Astoria an ideal data back-end for AJAX-style applications, and other applications that need to operate against data that is across the web.

To learn more about Project Astoria or download the CTP, visit the Project Astoria website at http://astoria.mslivelabs.com.

Project Codename “Jasper”
Project Jasper is geared towards iterative and agile development. You can start interacting with the data in your database without having to create mapping files or define classes. You can build user interfaces by naming controls according to your model without worrying about binding code. Project Jasper is also extensible, allowing you to provide your own business logic and class model. Since Project Jasper is built on top of the ADO.NET Entity Framework, it supports rich queries and complex mapping.

To learn more about Project Jasper visit the ADO.NET Blog at http://blogs.msdn.com/adonet

I was called in a few weeks ago by an architect on the Data Programmability team to give some advice about Project Astoria. The project is basically a way to create RESTful endpoints on top of a SQL Server database then retrieve the relational data as plain XML, JSON or a subset of RDF+XML using HTTP requests. The reason I was called in was to give some of my thoughts on exposing relational data as RSS/Atom feeds. My feedback was that attempting to map arbitrary relational data to RSS/Atom feeds seemed unnatural and was bordering on abuse of an XML syndication format. Although this feature was not included in the Project Astoria CTP, it seems that mapping relational data to RSS/Atom feeds is still something the team thinks is interesting based on the Project Astoria FAQ. You can find out more in the Project Astoria overview documentation.  

REST is totally sweeping Microsoft.

I've been reading a ton of blog posts containing developer reactions to Microsoft's Silverlight announcement at MIX '07. One thing that I've noticed is that people are coming to some of the same conclusions I came to in my post What Comes After AJAX?. Specifically, it is now clear that WPF/E Silverlight is a contender for the throne of king development platform for building rich internet applications (RIAs). Additionally, it is also clear that the days of Asynchronous Javascript and XMLHttpRequest (AJAX) being first choice when building rich internet applications are numbered. Below are excerpts of some of the posts I found interesting.

In his blog post entitled The Day the Web Changed: NET in the Browser! Jeff Prosise writes

MIX 07 opened yesterday and I believe we'll look back on that day as the day that the Web changed. Microsoft made several announcements, not the least of which is that Silverlight, formerly known as "WPF/E," will include a cross-platform version of the CLR that runs in the browser.

What does it mean? It means goodbye JavaScript, hello C#. It means managed code in the browser. It means an escape from HTML and browser DOMs and a better way to build browser-based UIs using XAML. It means incredibly rich browser experiences and a whole new generation of RIAs.

Soooo, ok, they released a new May CTP of ASP.NET AJAX futures. It's got some new support in there for Silverlight related stuff now. Great, awesome, love to see it and totally understand they need to pimp the new platform. What has really happened beyond that though?
...
Anyway, it seems like Silverlight is ursurping the development of the core AJAX futures and, while I'm all for Silverlight, I think it's a bad move to put these features on the backburner. They should be fleshed out and delivered. They are extremely valuable to those of us trying to build rich web browser (only) based applications.

I'd love to heard from someone inside MS on what exactly their intentions are at this point. If it's dead, fine... just let us know. If it's not, tell us what to expect and when to expect it so we can make decisions on how to proceed. I've said it before and I'll say it again, the stuff that was cut from ASP.NET AJAX 1.0 and ended up in the futures was much more important to developing rich internet applications and 1.0. It's true that 1.0 layed the groundwork, but having to cobble together all the UI in JavaScript still with $get and $addHandler, while possible, isn't what I'd call a good platform.

Drew Marsh also writes in his post Where's the MSHTML/IE news?

I find it strange that there has been absolutely no mention of what the MSHTML/IE teams are working on right now yet at Mix. I remember they stood on stage last year and talked about much shorter product cycles. Shouldn't we be expecting some kind of new enhancements by at least the early second half 2007? I really don't care about the IE shell, I care most about MSHTML coming up to speed with more/better support for CSS (gimme my selectors damn it!), enhancements to the DOM, etc.

Update: It seems I didn't provide enough context in this post because I assumed people reading this would also read my What Comes After AJAX? post. My point in this post isn't to state that Silverlight will kill AJAX. In my previous post I already mentioned that based on the data we have, Adobe's rich internet application (RIA) platform seems more likely to take the top spot than Microsoft's. Instead I was pointing out that we are further along the road towards replacing Asynchronous Javascript and XMLHttpRequest (AJAX) with a richer and more productive set of platforms. Additionally, if you read between the lines of the MIX '07 announcements, it seems AJAX is no longer the new hotness, given the lack of news on improvements to the Microsoft AJAX stack coming from the conference.

Popular consumer websites like Yahoo! Maps, Flickr, YouTube and MySpace have made rich interactivity mainstream and even expected when it comes to building a modern "Web 2.0" consumer website by using a post-AJAX platform (Flash). My thesis is that we will see more sites embracing post-AJAX platforms until we reach a tipping point where brand new Web 2.0 sites choose something like Silverlight, Flash or OpenLaszlo instead of AJAX when considering a platform for building a rich internet application. 

Yesterday I got a reminder that I've been gone from Nigeria a bit too long. I posted the following photograph and caption to my Nigeria 2007 Trip Photo Set on Flickr

One of the servants sitting down on the bed of his one room apartment.
You can see the entire apartment in this shot.

This photo and caption caused a bunch of outrage on certain Nigerian blogs leading to posts like A Presidential Servant and OBJ's Cribs as well as an angry comment on Flickr condemning me for calling the person in the picture "a servant". The person in the picture is a member of the domestic staff in my father's private home (not the presidential villa which is owned and staffed by the Nigerian government) who's responsible for serving guests, cooking and cleaning. The common term for this kind of job in Nigeria is houseboy. However since this term has been taken over by the gay community to mean something totally different (don't go to http://www.houseboy.com) I went for a non-ambiguous term that most of my readers would understand. From the answers.com definition for servant 

ser·vant (sûr'vənt)
n.

1. One who is privately employed to perform domestic services.
2. One who is publicly employed to perform services, as for a government.
3. One who expresses submission, recognizance, or debt to another: your obedient servant.

[Middle English, from Old French, from present participle of servir, to serve. See serve.]

What I forgot is that calling someone a "servant" is a derogatory term in Nigeria. I remember hearing the phrase I'm not your servant more times than I can count when growing up. So I've edited the caption and replaced "servant" with "member of my dad's domestic staff". I hope my Nigerian readers appreciate this change.

It's weird to experience culture clash when you're clashing with the culture you were raised in.