Konfabulator’s Missed Opportunities
In my post Dashboard and Konfabulator I said I disliked Konfabulator because it has a weak programming model. Defenders of Konfabulator may claim that comparisons to XUL or HTAs, both of which predate Konfabulator, are unfair and miss the point. As a pragmatic person I can sympathize with the argument that a tool is good if it meets a need. Nevertheless I found the programming model in Konfabulator to be dissapointing. It’s not my intent to slam Rose and Clarke and their work on Konfabulator, but I do want to highlight some missed opportunities.
Konfabulator 1.0 was released in February 2003. Now, a little over 16 months later, Konfabulator is at Version 1.7. Over that time there have been modest enhancements to its programming model.
Konfabulator uses TinyXml, a non-validating XML parser implemented in C++, and SpiderMonkey, a JavaScript engine implemented in C. (I don’t have inside knowledge. I know this from running strings on the Konfabulator executable and searching in the Konfabulator Forums.) At the heart of a Konfabulator Widget is a .kon file. A .kon file is an XML file that may also contain JavaScript code. A Konfabulator Widget’s appearance is largely defined in XML while behavior is largely defined in JavaScript.
JavaScript was popularized by its inclusion in web browsers. Web browsers have evolved to support dynamic documents. An HTML or XHTML document loaded in a modern web browser can be altered dynamically through DHTML and DOM methods exposed to JavaScript. Konfabulator does not support dynamic .kon files.
The services of the XML parser embedded within Konfabulator are not exposed to JavaScript running in Konfabulator Widgets.
Many Konfabulator Widgets are essentially web service clients. As there is no XML support in Konfabulator, SOAP and XML-RPC are not supported. Konfabulator provides a synchronous URL.fetch() method but asynchronous operations can only be performed by shelling out via the runCommandInBg() function.
Konfabulator has been said to be highly extensible. That’s true in the sense that a stone is a versatile base for soup. Following the same analogy the most valuable aspect of Konfabulator is the community that has embraced it.
Gadget Ghetto?
I didn’t attend WWDC 2004. What I know about writing a Dashboard gadget/widget comes from Dave Hyatt’s Surfin’ Safari.
The WebKit based programming model behind Dashboard’s widgets is broad and deep and too important to be relegated to Dashboard only. James Duncan Davidson discuss Mac OS X as a “pragmatic platform.” That gives me hope that WebKit based apps will become a viable choice for desktop development.
Related Reading
SitePoint DHTML & CSS Blog: HTML escapes the browser
Daring Fireball: Konfab Confab
Michael Tsai Blog: Gadget Development
Comments