Category: Technical

Back to the Missing Future

I got back last night, but was too tired to get online.

Eric Kidd, a 27 year old programmer, writes about the Missing Future for small software developers, the magic dust that made Silicon Valley and Microsoft possible in the first place.

"But this dream is nearly gone. It's getting crushed between the awful power of Microsoft, and the onrushing juggernaut of open source." – Eric Kidd via Dave Winer

He echos my post from last year:

Between Microsoft monopoly and Open Source religion, I fear software market is between a rock and a hard place. – Don Park

Universal Robots tag

Current standards for robot exclusion, robots.txt and robots META tag, are effective only for page level robot exclusion directives.  In light of Google versus Blog controversy, I think it makes sense to introduce finer-grained robot exclusion tags.  Here is a sketchy proposal:

<robots> Tag

<robots> tag advises web robots whether data and links following the tag are indexable and/or followable.  <robots> tag may be used in HTML or integrated into XML application-specific schemas.  It has only one attribute, 'content', with same case-insensitive values as the content attribute of the robots META tag, specifically ALL, NONE, INDEX, FOLLOW, NOINDEX, NOFOLLOW.  'content' attribute is required.  <robots> tag is an empty tag, meaning it has no child elements nor textual contents.

<robots> tag's namespace URI is "http://www.robotstxt.org/xmlns&quot;.  Namespace declaration is not required in HTML documents.

HTML Example:

  <robots content="noindex" />
  <table id="blogroll">....</table>
  <robots content='index' />
  
...

XML Example:

 <channel>
 <robots content='none'
 xmlns="http://www.robotstxt.org/xmlns"/>
 <title>Don Park's Blog</title>
 ...
 <item>
 <robots content='all'
 xmlns="http://www.robotstxt.org/xmlns"/>
 <description>...</description>

Processing Guidelines

  • With HTML documents, robots may search <robots> tags by searching for string pattern "<robots" to find next indexable and/or followable areas of the document.

iTunes: Death of Record Companies

Check out this short Business 2.0 piece showing how each dollar collected per song is divided up.  Artists get 12 cents out of a dollar.  The music download service (i.e. Apple) gets 40 cents.  That leaves 48 cents up for grab as music download industry emerges, expands, and consolidates while the real world music distribution business shrinks.  I expect record companies will start to dwindle during the expansion phase as they start losing artists to the music download industry.  There will still be middlemen, but record companies will be left with peddling only oldies.

javax.comm rant

Here is another great post from java.net weblogs about another orphaned Java package: javax.comm.

"If Sun really wants to see Java applications on the desktop, it needs to finish the tools–all the tools–that people need to write those applications. And that includes javax.comm. I couldn't argue that javax.comm should be a high corporate priority, but there's a solution to that: contribute javax.comm, javax.sound, and any other APIs that have been orphaned over the years to the community. The "write once, run anywhere" story is GREAT, and it REALLY WORKS–but it doesn't count if it's "write once, run anywhere, as long as you don't need to talk to any devices out there."

Would I want to live in Laszlo?

By nature, I am enthusiastic and generous with complements as well as criticisms.  So it is understandable for some of my readers to think my recent posts on Laszlo are outright recommendations for Laszlo.  They are not.  I thought I should make this clear before the confuson spreads any further.

What I have written before are what an excitable traveller might have said while touring through Three Gorges or Grand Canyon.  This post is what the traveller might have said at the end of the trip, in response to the question "Would you want to live here?"

In short, my answer is no.  I will have to post the longer version later, but my answer has a lot to do with why I decided not to pursue an idea similar to Laszlo while back.

I apologize if I confused you.  I believe in simplicity, but I am far from being a simple person.

Improving Laszlo

When I am onto something, it is difficult to let go.  Laszlo has been on my mind all day.  Here are some thoughts on improving Laszlo:

Laszlo IDE

Laszlo needs an IDE.  Currently people are expected to use whatever editor they have to edit LZX files.  Eclipse is the best IDE technology out there, so integrating Laszlo with Eclipse makes sense.

Faster LZX Compiler

Engineers should not have to wait to see the result of changes they made during development, particularly at presentation level.  I don't know why LZX compilation seem so slow, but this must be fixed ASAP.  Here are some options:

  • Compile Laszlo and JGenerator to native code
  • Incremental LZX compilation
  • Finer-grained SWF generation and caching
  • Client-side weaving of SWF fragments

Wizards

Provide wizards to ease common tasks and solve common issues such as Page Back and Browser Resize problems.

XML Baby Talk

I had been expecting baby talk versions of complex XML formats to emerge for sometime now.  It hasn't happened yet so I am left with scratching my head.  The idea is simple enough, take a complex format and create a user-friendly version that maps to the more complex version via an XSLT file.

Inside Laszlo

I spent a few hours last night playing with Laszlo and liked what I saw.  Laszlo address many Flash shortcomings, allowing programmers to use Flash as front-end for web-based enterprise software without dealing with all the mess that has piled on top of Flash all these years.  Having spent a lot of time on a similar idea, I know that what they have accomplished is an impressive feat.  Frankly, I don't think I could have designed it any better.

Laszlo pulls together many open source Java packages such as:

  • Axis – for web services
  • Batik – for SVG support
  • FOP – for XSL-FO support
  • JDOM – for simplified DOM manipulation
  • JGenerator – for SWF generation
  • Jing – for RELAX NG validation
  • JXPath – for XPath support used to select dataset nodes
  • Jython – don't know what for yet (it's Python on Java)
  • OpenOffice – probably for OpenOffice file format support
  • Xerces/Xalan – for XML parsing, DOM, and XSLT
  • XPP3 – an implementation of XmlPull API

Laszlo can be most readily integrated with J2EE applications because it is entirely Java-based and LZX, Laszlo's XML-based Flash UI description format, can be generated easily with JSP.  Following diagram shows how this works:

Hello.html is just a static page that embeds a movie returned by Hello.jsp.  Browser loads Hello.html which causes the Flash plugin to fetch a movie from Hello.jsp.  Hello.jsp emits LZX, instead of HTML, which is used by Laszlo to generate and return SWF.  With minimal efforts, other control flow can be used and processes can be added (i.e. XSLT) as long as LZX is fed into Laszlo in the end.  Neat.

There are, however, some issues with Laszlo that affect developerment and user experiences.

First, LZX to SWT conversion takes a while, much longer than JSP compilation.  Add up everything and you got enough delay to affect development experience.

Second, a Laszlo-based webpage is slower to load than DHTML-based webpages.  This is understandable because a Laszlo-based webpage can handles a lot more interactions with the user before having to reach out to the server than a DHTML-based webpage.  Still, the delay is noticeable enough to affect user experience.

Third, browser integration problems with full Flash-based webpages are still there.  For example, pressing the Browser's Back button will not work properly.  There are other similar issues that must be addressed soon.

There is much I like about Laszlo, particularly the power of LZX.  LZX's extensibility is impressive.  I need to spend a few more hours later to look deeper under the hood, but what I like about Laszlo are these:

  1. Harmonized with Java-based web applications – you write your backend in Java and drive Laszlo using LZX tags from JSP.  This allows you to leverage your existing investment in Java.
  2. Smart use of Flash – you still need Flash to generate graphics and animation resources used by LZX tags.  This means Flash developers in your team can focus on what they know best.
  3. Good People – I am impressed by the talents behind Laszlo.

[Sorry about the shitty diagram.  I could have used Visio, but I also needed more lazy learning time with GraphViz.  Since I still don't know enough about dot to generate good looking diagrams, result is what you see above.]

Java.net Weblogs

Weblogs are important part of Java.net although one needs to stroll around a bit to find them.  I usually go here to find new articles.  Here are two articles worthy of mention this week:

In Whats up with the JavaSound team?, Jonathan Simon discovers that entire JavaSound team split a while back and now there is just one hardworking guy wearing many hats.

This is ridiculous on a number of levels! How does Sun expect to put out a decent product with a single guy responsible for all of JavaSound? Also, the code was poorly designed to begin with, and Florian can't even really change it! So whats left is a really buggy, poorly designed library that is on every Java enabled PC!

Michael Champion, an old compadre from XML-DEV, answers the question "When does SOAP add value over simple HTTP+XML?" and concludes with:

It's just as "wrong" to blindly reject SOAP as to blindly accept. it.

<

p dir=”ltr”>Right on, Michael.