March 2003 Archives

I've released mt-rebuild, a utility script for rebuilding a MovableType template from the command-line as opposed to the standard MT browser interface. This is particularly helpful when combined with cron to automatically update a part of your site on a regular basis. An example would be the updating of syndicated content feeds using the mt-rssfeed plugin.

This script depreciates its more limited predecessor mt-rebuild-index that was included in the mt-rssfeed plugin package.

The script can be downloaded from my MT plugins page.

Macromedia announced Flash's independence from the browser and an associated marketplace for Flash applications called Central. This is a very positive setup towards Flash's adoption as a microcontent client development platform and application-centric mate for the browser. The issue of a Flash application development tool for programmers is still left unresolved. I wish for a Flash application compiler. More on my O'Reilly weblog.

UPDATE: Seems my wish could be coming true sooner then I thought. Macromedia's Mike Chambers writes on the tantilizing Royale project that was shown a the FlashForward conference today.

(Cross-posted on my O'Reilly weblog. )

In a Sun InnerCircle publication Sun Chief Technology Evangelist Simon Phipps writes:

Still, despite wide consensus, the technologies usually associated with Web services are not actually standards or recommendations of any open standards organization. To the surprise of many, Web services are not just about SOAP and things that start with WS-*, as some vendors would like you to believe. Some of the most widespread Web services today — for instance, those in use by the fast-growing Web-logging ('blogging') community — are based on other technologies like RSS and XML-RPC.

I'm glad to finally see a major technology vendor acknowledge SOAP etc. is not all there is to Web services and that RSS as a legitimate technology in that space. Given its emerging uses, RSS is not just a format for syndicating content. As I've written in the past and others have noted, RSS feeds do qualify under the principles of the REST architectural style that the Web was built on.

Simon's mention of weblogging raises a question I've been meaning to ask for some time. Are there any Sun employees blogging? Microsoft and IBM have a handful that I know of off the top of my head. Macromedia is the model corporate blogging citizen with some significant top brass ( Kevin Lynch and, until recently, Jeremy Allaire ) making regular posts.

If I haven't overlooked any Sun employees blogging, this is quite an oversight. Microsoft is not the only company that could use a human face.

UPDATE: In my original post I omitted that I think Apple's Safari developer extraordinaire David Hyatt weblogging his work and views is marvelous and another great example of bloggings potential in these firms. David's communications with his existing and potential user base not only interesting, but provide me with a sense of understanding and confidence in his (and Apple's) work.

Also, some Sun employee blog sightings are coming in via private email and the comments on my O'Reilly weblog entry. One of these includes Simon Phipp's own personal weblog.

Lastly, you may have noticed that I ignored Simon's mention of XML-RPC. While it certainly has its uses today, the limtiations I've come to know leads me to not support its proliferation going forward. Its flaws are serious. Today, in randomly surfacing around, I happened upon this rant by Charles Cook on XML-RPC and weblogging APIs that covers some of the significant shortcomings quite well and figured I share the link and state my view.

CNET is reporting that Sun Microsystems plans to simplify Java software development by combining portal and integration software in addition to releasing Sun ONE Studio. According to the article, Sun executives said the new tool will be targeted at developers that have a Visual Basic skill level. Microsoft's Visual Basic is easier to work with than most other programming languages.

Making development easier is certainly the right idea, but attempting this with the Java programming language seems to be an oxymoron. Being that I'm a recovering Visual Basic guru and having some knowledge of Java, I know.

I think a complimentary scripting mechanism for working with Java beans and services would be more effective and appropriate to making the Java family more accessible and more useful. Support of ECMA/JavaScript would be ideal because its fairly simple to learn, reflect's Java OO nature and has its own extensive developers community. Its also platform-agnostic and its not Microsoft's. ;)

It probably wouldn't take much to develop. In many ways, though not all, this would be along the lines of IBM's Bean Scripting Framework (BSF). There is also the Rhino project which has ported the Mozilla scripting engine into a Java form.

This approach would be a more effective way because skilled Java programmers can focus on complex and intricate tasks and let less skills staff (perhaps even tech saavy business users) rapidly glue that functionality together. Don't forget these skilled programmers sometimes need to get apps done quickly – like a prototype. Sometimes they have to ship that prototype.

Back in February Jon Udell wrote about refactoring the enterprise where he quotes Ward Cunningham extensively. Ward explains it best when he says:

There is a huge opportunity lurking up ahead. The enterprise guys don't know it because they think scripting is for sissies. The scripting guys don't know it because they think business problems are already simple and don't have to be made that way.

Jon continues.

Modern scripting languages have two important properties that qualify them for [scripting the enterprise in business terms as well as in IT terms]. First they use fewer tokens (words) to express concepts. When you look at a program and try to reason about it, says Ward, the fewer the tokens, the faster you can reason about them – that's important. Second, their powerful and fluid object models support continuous refactoring. Ward says it plainly: You get to make the words say what they are.

What they are, increasingly, is business processes. And here we run into a major disconnect. To the enterprise, scripted solutions look like one-offs, not strategic systems designed to high standards of quality and able to evolve along with the business. What the enterprise folks don't get is that scripted systems can be engineered to meet these requirements. So they lean toward C++ and Java, and then rely on powerful integrated development environments, like Eclipse and IntelliJ IDEA, to make fluid refactoring possible. These tools can work very well. They're complicated, observes Ward, and you have to learn how to work them – but boy, when you do, they make those languages start to feel like scripting languages. On the other hand, he asks, Why should we need heroics in the IDE to correct for misguidedness in the language design? It's a question of suitability for purpose. If the purpose is to continuously evolve programs for business, then what's suitable is to have clean object models that are easy to read.

Java cannot be all things to all people. (Is it really appropriate to make user learn Java for writing macros to automate their business documents as porposed in StarOffice? No, its not.) Java does alot of things well, but with great power comes great headaches. Creating more sophisticated and fat tools to abstract programming language complexity does not really solve the problem, but defers it – perhaps even make it worse. Besides abstractions always leak.

It will be interesting to see what they eventually come up with though I do miss the days when Sun would create innovative and original technology and not try to copy someone else. (They do the former better.)

The Net::TrackBack module (formerly XML::TrackBack) has been posted to CPAN as promised when initially released. The only changes in this release (version 0.21) is the switch in the module heirachy to the more appropriate Net branch and the inclusion of a make file.

My latest O'Reilly Network article has been published – Developing Movable Type Plugins

In this article I cover the MT plugin framework, its complete API, and the basics of hooking into the core systems operation and its data persistence service. With the richness of Perl and the MT system, a whole book could be written on the subject. I stick to the basics in a whirlwind tour.

You need to be somewhat knowledgeable with Perl and familiar with its OO style to follow along.

While I'm getting any real work done today having unleashed my dormant mobile computing thinking, Mark Pilgrim writes about his weblog's mobile edition concluding:

As I said, XHTML Basic has no basis in reality. Ignore it.

Certainly his points are understandable though less so outside of the US. I don't think you'll be able to ignore it very long though.

XHTML Basic is the underlying markup language of WAP 2.0 that replaces the wrong-headed Wireless Markup Language (WML) of version 1.0. Despite all of its foibles and my own harsh criticism, WAP still has the support of all the major telcos and handset manufacturers of the world for browser based applications. Most notable is Japan's NTT DoCoMo who operates i-Mode, the most successful (by a landslide) mobile Internet service in the world. Replacing WML with a standardized XHTML subset was the key concession to getting NTT to endorse WAP and migrate away from its own HTML subset called cHTML. A good, but somewhat dated summary by Wired can be found here.

Are an extensive amount of devices with WAP 2.0 out there? Not really, but look for that to change in the next year or so. So enjoy ignoring it while you can.

There are zero occurrences of the word asynchronous in the current JSR 172 (J2ME Web services) draft specification. If there is one place where asynchronous messaging is most needed its with the unreliable low-bandwidth mobile networks that mobile phone and PDAs operate. More over on my O'Reilly Weblog.

What a glorious day today is. It’s been around 60 in the NYC metro area today. I'm not spring guy, or even summer for that matter, but there is always something rejuvenating about that first day when you feel the winter thaw ending.

So if any one is walking around the Jersey City waterfront today and wonder who blasting all the retro alterna-dweeb music (The Psychedelic Furs, The Cult, Erasure, The Mighty Lemon Drops, The Cure, Big Audio Dynamic, The Yaz, New Order, Sisters of Mercy) – that would be me.

I've been truly enjoying David Hyatt's commentary on browsers since he started. I wish more people working for major technology firms did this. In this post, David gives his commentary on the latest anti-Mozilla article What if Netscape had won? from CNET's Charles Cooper.

Well, first off, that's a pointless question, because it was absolutely impossible for Netscape to win against Microsoft once Microsoft bundled their browser with the operating system. Sure, technically Internet Explorer 4 was superior to Netscape 4, but even if Netscape 4 hadn't been, would it have mattered? No, of course not. Just look at how far beyond Internet Explorer other browsers have gone, and do they have any substantial market share? No.

This gets back to my earlier blog about avenues of distribution. Without them, your browser gets nowhere. Microsoft controlled distribution on the platform that 97% of the world used. Therefore they won. End of story. Asking What if Netscape had won? is like asking What if the Earth started rotating in the opposite direction tomorrow? It's not even worthy of speculation.

After noting the extensive innovation and improved features of other browsers he finally concludes:

From Opera's page zoom to Omniweb's bookmark scheduling to Phoenix's popup whitelisting to the Web services support in Mozilla, browser makers are innovating everywhere! The problem is not that we, the browser makers, aren't innovating. The problem is that you apparently aren't using the browsers we produce.

Agreed. Perhaps writing an editorial where he asks What if Microsoft wasn't an abusive monopoly? would be more interesting and relevent.

Rainer Brockheimer Brockerhoff (Sorry, Rainer!) recently made a post on recent developments to utilize TrackBack and other related technologies. I'm in general agreement with Rainer and Tom Coates, whose writings he also cites in his post. The following quote I believe requires some clarification on my part being a proponent of this cause:

…the whole trackbacks are comments movement is an attempt to make weblogs more like bulletin-boards.

I can say this is not my primary motivation nor do I believe it is for others involved in this discussion though certainly these notions descend from its lineage. Furthermore, I don't see these efforts as a desire to claim a territory unexplored when its patently not. To me this work is only an evolution or a reformulation of past.

Let me share my thoughts in an attempt to elaborate and perhaps clarify the matter.

First, I think it worth noting again and in more direct terms that the history of bulletin boards are not lost on me in the least. I have not specifically mention it and perhaps I should have. (I suppose I'm changing that right now.) The fact of the matter is that my experiences with bulletin boards drive my interest in TrackBack, weblogs and the convergence of these related technologies.

My personal opinion is that bulletin boards (as Mark Pilgrim would put it) suck. They are generally an unfocused collection of threads that, until RSS becomes commonplace, require me to come to it and use its interface to comment. The threaded display makes it even harder for me to grok particularly when it’s a highly active conversation.

Weblog comments only slightly improve on this by organizing the conversation to a single thread and quite often (and thankfully in my opinion) display them in a flat rolling manner. These discussions are also started by one or a select few individuals that typically increase their quality. While many are beginning to take advantage of the RSS generation functionality found in weblogs tools, weblog comments still require that I use their interface. Furthermore those comments are limited to that one weblog unless I cut, paste and post them elsewhere.

How are TrackBack-enabled comments different then past means? The most important is that, as a commentator (the not for us Tom Coates writes about), I have options to the way in which I want to share my thoughts – through the interface of the weblog I'm commenting on, a post to my own weblog, or a specialized external application. This is significant because it allows information and knowledge to flow more efficiently and more frequently.

A key differentiator is that TrackBack-enabled comments have a standardized remote API. It's my belief that this capability could give rise to tools that allow prolific power commentators to work from one interface. They also allow for me to comment from a post to my weblog. It's also noteworthy that the distributed loosely coupled nature of TrackBack-enabled comments (quite a mouthful) can be organized and grouped by the individual. (This of course assumes that individual is so inclined. I would because I think some of my best thoughts are not on my weblog.) Bulletin boards and weblog comments alone are constrained to a specific site and grouped by a certain topic or theme.

I would not be making this post for I didn't even know of Rainer until he pinged one of my entries yesterday. (I'm glad I do now.) Nor did I know that Tom Coates wrote about the excesses of social software earlier this year. It's situations like these that make the potential value of TrackBack-enabled comments come into focus and subject to exploration as an evolution of past mediums.

Note that in discussing TrackBack that I use words such as could and potentially. This notion is still a work in progress and not without its flaws.

So while I generally agree with the view Rainer and Tom expressed, we see the same circumstances differently. Social software like TrackBack-enabled comments are an evolution of the past not an isolated reinvention of the wheel. Innovation commonly happens in isolated pockets where similar discoveries are made until finally someone maps their triangulation and they come together. Social software like TrackBack manufacture serendipity and bring them together faster then in the past.

Joe Gregorio via Sam Ruby. This version of RESTLog that I am running also supports the CommentAPI. The easiest way to explain it is that you can post a comment via posting an RSS item fragment.

This is great, but what I'd really like to see is TrackBack and Joe's proposed API to merge into one. Remember TrackBacks are Comments are TrackBacks.

In related news, Rael Dornfest released a commenting system for as Blosxom 2.0 as a plugin utilizing the standalone TrackBack system called WriteBack. (I like this name for combined TrackBack and Comments.)

Once I finish get TikiText up more finished off, I have to return to my TrackBack NG advocacy.

UPDATE: I've released a patched version that corrected a few reported issues. More detail can be found here.

I've released a new version of the TikiText engine. It was time.

This release is an extensive refactoring bordering on a rewrite to address some of the issues I encountered in previous versions and the realization the road I had set out on was flawed for future development. This new release also adds the beginnings of some highly requested features – images (though not feature complete) and tables.

In addition to images and tables, the following changes where made to this release:

• Changed code symbol from | (pipe) to % to make way for tables.
• Blockquotes can be nested.
• Blockquotes can contain lists and other block formatting.
• Switched to WikiWord target names as opposed to camel case.
• One line definitions and terms are no longer supported.
• <pre> blocks can included TikiText notation. TikiText is still ignored in <code> blocks.

Download:
.ZIP
.GZ
Reference Guide 0.5

This ended up being a rough and circulative process and not what I initially imagined. As previously mentioned
I thought …in terms of processing, TikiText is not much different then XML. What I found (the hard way) is that, while similar, there where enough difference to make the streaming token method I first attempted was too difficult if not impossible when you do not have explict and easily identifiable end tags.

I have a new appreciation for the elegeance and simplicity of XML markup. Not that I didn't have one before – its just grown the size of the Empire state building and illuminated in neon.

The code still needs a lot of cleaning up and some optimization, but it works.
I've checked for the bugs that where reported and think I have addressed them, but with such an extensive refactoring I fear I may have introduced new quirks and bugs. I have identified a few minor quirks already that I've listed in this version's documentation.

Comments and bugs can be placed here. As always bug reports and feedback are appreciated.

Some of you may think that Goggle acquiring Pyra is a landmark event for blogging in the mainstream. Well I got news for you – that ain't nothing. Barbie is now blogging. I kid you not!Mattel is marketing a new line of Barbies targeted towards 10-14 year olds. Each doll has her own site, and her own blog. Now that is called going mainstream. (Tip via Jim Coyle.)