Friday, October 21, 2005

Palm: 1992-2006?

I got dragged onto the Palm bandwagon in 2000, but the sad fact is that its main advantages over a Filofax are the following in descending order of importance:
  • fits in my pocket
  • holds tons of data without getting larger
  • can beep at me to remind me of something
  • synchronizes with my desktop computer
  • runs software
There isn't one of these that doesn't apply to smartphones, and Apple forsaking Newton for iSync was the writing on the wall. While a programmer posting anonymously at OSnews is correct that PalmOS development is pretty much "compile once, deploy everywhere," he's also evading the other truth: that in order to make PalmOS small and fast, the firmware sacrifices enough characteristics of a conventional platform to make porting apps a chore.

Platform historians are going to have a hard time resisting the impulse to paint Palm's history as a flawed copy of the Macintosh. As a former Apple employee, Jeff Hawkins never objected to the comparisons made by the press.

It's an apt parallel to what happened with the original Macintosh, beyond the obvious Motorola 68K/monochrome screen. Design decisions made 10 years before held back the platform, and it took dumping nearly everything that differentiated it in favor of a more standardized OS and hardware to sustain the product name, while carefully maintaining five years' worth of compatibility to make the transition palatable. A faster CPU replaced a 68K and the OS shipping for it was essentially a recompile for the new architecture with a bytecode translator.

Unfortunately they followed Apple's mistakes as well. Spinning off software divisions, releasing too many new models with incompatible hardware and not enough improvements, and taking their momentum over Microsoft for granted.

Ultimately PalmSource made the critical mistake Apple avoided: they thought their future lay in BeOS, wasting a year trying to shoehorn its features into PalmOS before realizing they had zero clout with Palm or its hardware licensees. Cobalt died on the vine. Partners like Handera, Symbol and Tapwave either folded or switched alliances to Windows as laptops got cheaper and smaller and SCO's legal troubles made it relatively clear that Linux was a viable alternative for smartphones.

And Linux is where PalmSource claims PalmOS' future lies, with a new kernel but the same API. Unlike the OS X transition that supplied every Mac user with a fully fledged instance of BSD Unix, the Linux PalmOS won't be a Zaurus running Linux with a recognizable file structure. It's merely an architecture change to make PalmOS easier to port to as-yet-unknown smartphone platforms.

Nevertheless rumors abound that PalmSource's corporate masters have no use for PalmOS.

When everyone got on Wifi, Palm lagged until well after every one of their competitors made it a stock feature. The Windows portable platform rides Microsoft's coattails; iPods feed off iTunes' ubiquity. PalmOS lacks an equivalent lifeline, and Palm's decision to stop supporting MacOS cuts the philosophical tie that founded the company.

The LifeDrive is a solution looking for a problem, and a rushed one at that: a cold restart reformats the hard drive -- and it still can't run any OS except the one burned into it.

The most important lesson geeks and nerds need to take away from the 90s if they didn't cut their teeth in the 80s is this: the commercial computer business is not a meritocracy and it never was.
  • Better products will be steamrolled by cheaper ones.
  • Cheaper equal quality products will be ignored in favor of ones with dumbed down interfaces, European designers and flashy ad campaigns.
  • Businesses will choose the bigger company over price, quality or dependable standards, every time.
If you're an idealist, stick with BSD or Linux.

There's no such thing as an HTML comment, and why that's important

If a comment contains 2 consecutive dashes and its document has an XHTML doctype declaration, Gecko-based browsers like NS 7 and Firefox will show the content after the double dashes. The reason is convoluted but understandable:
  • In the SGML spec, <!--this is a comment--> is actually two nested sets of delimiters:
  • The <! and > are SGML declaration delimiters. Declarations are usually self-enclosed structural definitions meant for a parser, not content meant for a viewer, and do not look or behave like HTML tags:
    <!ELEMENT gallery (imagebase*,image+) --an imagebase child element is optional, but there must be at least one image-- >
    Declarations abound in other kinds of SGML documents (such as DTDs), but HTML only demonstrates one in action, the doctype:
    <!
    DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  • Inside declarations, double-dashes are the actual comment delimiters (see the example with ELEMENT above).
  • Because HTML comes from SGML, its creators saw no reason to reinvent the wheel. Instead of creating an HTML comment tag, they reused an empty SGML declaration with SGML's own declaration comment syntax. There is, in fact, no such thing as an HTML comment tag. When the W3C released the HTML spec, they only reiterated this fine grained point in a separate document comparing SGML and HTML, because they figured everyone was familiar enough with SGML's 15-year-old standard to understand this already. Double-dashes are comment delimiters in several programming languages, and "dash-dash-space-endofline" is the delimiter used by mail programs to separate your message from your sig.
The authors of NCSA Mosaic, the first browser, likely reasoned that in the absence of any other SGML declaration types besides doctype, there was no need to parse "HTML comments" beyond the predictable <!-- and --> start/end pair. Newcomers to the browser-writing scene unfamiliar with SGML assumed this pair was one set of delimiters, not two. The distinction is almost academic.

Doctypes change the rules. Remember, doctypes are declarations, and declarations define a parser's behavior. In their absence (or in the presence of an HTML 4.0 doctype), browsers typically revert to "quirks mode," which often means they parse HTML using the parser they had in 1999. Add an XHTML doctype, however, and the document will be parsed to stricter guidelines more tightly conforming to XML spec...

...in theory. Gecko browsers (Mozilla/Firefox/Netscape) currently enforce SGML comment syntax in the presence of an XHTML doctype, IE and Opera do not. For now, there isn't much more incentive than there was in 1999; however, as browser based XML/XSLT web apps take off, parsing the XML datasets' custom DTDs will become more necessary, and as hinted before DTDs are just a laundry list of SGML declarations. Given their common heritage and syntax, it's conceivable that a browser's DTD parser and the XHTML/XML/XSLT parser will merge enough to use the same rule for SGML comments in all contexts.

You'll see more SGML in web pages in the future, especially when web servers start using XHTML's correct MIMEtype and stop using HTML's "text/html". This change in MIMEtype triggers even stricter XML parsing in Gecko and Opera, which means that XML-nonconformant content such as JavaScript and CSS inside web pages have to be escaped with <![[CDATA]]> blocks. (If you're using external .css/.js files none of this is an issue.)

Unlike SGML comments, CDATA doesn't hide content but tells the XML parser to ignore it as raw character-based data (similar to how the PRE tag works) and thereby allow JavaScript/CSS operators like < > -- to exist without triggering the error that started this article. Remember, this is 2005 and the number of browsers today which still attempt to render the contents of style/script blocks as text is practically nil, even counting microbrowsers, Lynx, and Netscape 4.7. SGML comment hiding of style/script blocks is unnecessary and deprecated.