Safari for Windows.. why?

A lot of people seem to be pondering why Apple would port Safari to Windows. Safari is a minor player, so why bother? I can think of only one answer: iPhone and offline browser-apps

The iPhone has a Safari derived browser build it. Apple didn't talk about it, but if the browser is the development platform, then there must be something like Google Gears coming. If they want to get a large number of people building apps for the iPhone, they need to support development on Windows. The first step for that is Safari on Windows.

just my guess...

Useful tool: Synergy

I saw a reference to Synergy on LifeHacker.com today. I know I've seen this before, but never really investigated. I now have it running on my work desktop (what better to do while I wait for tests to finish, and traffic to clear?). My normal setup is my laptop connected to a Dell E207WPF, and my workstation connected to 19" lcd next to it. I use a KVM switcher so that I only need one keyboard and mouse (and so the workstation can use the E207WPF). I do most of my work on my laptop, but I like to use my workstation for random tasks that I don't want to interrupt my flow, be they test runs, performance timing, or just iTunes podcasts. Switching back and forth is slow and annoying.

Synergy to the rescue. I now have my laptop set up as master and the workstation as slave. I can hop between machines with trivial ease. Well done.

Why use XML for serialization?

In my recent post about WADL, I mention some of the problems with using XML as a data serialization format. In the comments, Eric asks why use XML for serialization at all? Browser-based apps are rapidly moving to JSON. Ruby developers prefer YAML. If XML really is such a mismatch for modern programming languages, why bother to use it?

I could argue about the availability of tools (XSLT/etc) to process XML. At AgileDelta, we often use E4X to help customers filter or reformulate their XML data. At Microsoft I often used XSLT, or MSXML + JavaScript to do quick-n-dirty processing of XML data. Really, JSON and YAML have a bit of an advantage here, because you can use the full power of your scripting language.

JSON is actually a hugely better than XML fit for many data serialization scenarios. It is more compact, faster to parse, and less ambiguous about how to map to your data-structures.

Where XML really has an advantage, is for formats which mix markup and data. Atom/RSS is a perfect example, as is XSLT. You could do ATOM is JSON, but then half your data is in one encoding (JSON) and the other half is in another (embeded HTML). With XML you get both, which is a huge boon when trying to process the data.

The other place that XML starts to have an advantage, is when you start having to support cross version compatibility. Eventually, you are going to have to write a loader that translates v1 data to your v2 data-structures. Browser-based apps can mostly avoid that. Enterprise apps can not. The closer you get to the database in a multi-tier app, the less that strategy works. The real benefit is that XML already gave you a serialization abstraction, so implementing data transformation becomes trivial. I'm not saying that this data transformation is not possible with JSON/etc, just more difficult.

Playing devil's advocate for a second here... given how few apps live long enough to actually need real back-compat layers, maybe the benefits of using JSON for V1 are worth it. Who cares if V2 is a days more work, if JSON shaved a week off your V1 schedule.

Back on point... XML helps by forcing a slightly higher level of abstraction. That also is realized by providing better facilities for validation of message contracts. As much as I dislike WADLs focus on XSD to the benefit of building RPC-like tools, XSD for message validation can be extremely useful. (Or use Relax-NG, or whatever other XML Schema language you happen to like) It provides a clear specification for what a message must look like. One of the down-sides of JSON/etc is that they tend to go unspecified. It takes a lot more work to ensure that your are not writing out properties that were not intended, for example. XSDs are not particularly useful in production, but they can be invaluable in development and testing.

So why use XML for serialization?
1) your data is a mix of marked-up text and structure
2) abstraction to simplify contract validation and cross-version compatibility

You could theoretically get most of (2) with JSON/YAML.. someday. XML provides that out-of-the-box today.

WADL: its really about the XML APIs

There has been a bit of hubbub about WADL recently. Much of the conversation is about the need to describe the message using XSD and the benefits of WADL/WSDL for tooling. (I'd provide a Technorati search link, but Technorati appears down at the moment.) I think the real problem is that most XML APIs are so horrid to use. People want RPC (at least until they get burned enough to know better), and even when they know better they was the initial simplicity of RPC. One of the big problems with XML is that it is a horrid match with modern data structures.

You see, it is not that it isn't trivial to figure a way to serialize your data to XML; it is just that left to their own devices, everyone would end up doing it slightly differently. There is no one-true-serialization. So, eventually, you end up having to write code to build your data structures from the XML directly. The problem there is that virtually all XML APIs are horrible for this kind of code. They are all designed from the perspective of the XML perspective, not from the data serialization perspective.

It gets worse. XML is one of those things that looks really easy, but is actually full of nasty surprises that don't show up until either the week before you ship (or worse.., a few weeks after). Things like character encoding issues, XML Namespaces, XSD Wildcards. It is really hard for your average developer (who makes no pretenses at XML guru-hood) to write good XML serialization/hydration code. Everything is stacked against him: XML APIs, XML -Lang itself, XSD.

That is why so many developers (especially in the Java world) just use XML Binding layers.

Solution? Give them a good XML API. Not one designed for XML Gurus, who understand every nuance of the spec. Give them an API that makes using XML easy, and relatively efficient. This ain't easy, or it would already be there. XLinq is C#'s answer to exactly this issue. Java needs something similar. An XML API that isn't designed primarily for XML as text markup, but an XML API that is designed for data serialization.

XML Tools screen-casts

Before leaving Microsoft, the last thing I worked on was the XML Editor in Visual Studio. In Visual Studio 2005, Microsoft shipped one of the best XML Editors out there. Intellisense, XSD syntax support, XSLT syntax support, XSLT Debugging, XSD Schema auto-generation. There is an incredible amount of functionality hidden in there.

One of my favorite 'hidden' features is goto-definition. Position the cursor on an element in a document with an associated schema, and F12 will jump you to the part of the schema that governs that element. I occasionally get some very complex customer schemas. F12 can also be used to navigate with-in a schema, from an element declaration to the declaration of it's type, or to the base type declaration. When the schema spans megabytes and multiple files, this is invaluable.

The XML Team just released some screen-casts of existing and future functionality. If you use Visual Studio and ever have to edit XML files. Watch Stan and you will almost certainly learn some new tricks.