June 2002 Archives

The Bill Gates Mac switcher parody over at macboy is a must see for a good laugh -- unless you're a cranky pundit named John C Dvorak. Link courtesy of Chuck Toporek's weblog post at O'Reilly. Ironically the page is not coded properly for viewing with Mozilla.

I've installed MovableType 2.2 and made some modifications to my weblog including the addition of TalkBack on some select entries I want to encourage others to link to. (Look for the TalkBack link at the footer of an entry.)

This entry also is linked to another TrackBack enabled page: Feature: TrackBack.

This is a great new feature. Good job Ben & Mena!

Intertwingularity. Manufactured serendipity. Triangulation. Neighborhoods. Its too late at night to fully wrap my head around what this new feature could mean, but I sense this can only be goodness to experiment with and observe.

The latest version of MovableType (version 2.2) has been released by the dynamic duo of Ben and Mena Trott and its a dandy. An intruiging new feature has been added called TrackBack. From MovableType's documentation:

Movable Type's TrackBack system allows peer-to-peer communication and conversations between blogs. Imagine that you write about a movie you just saw in an entry on your Movable Type-powered blog. Another MT blogger reads your entry, and wants to write an entry referencing your original post. He could just comment on your blog, but he'd like to keep the post in his own database and host it on his site.

TrackBack itself is a framework for peer-to-peer communication between weblogs; it can track cross-weblog discussions, it can provide remote content repositories, it can emulate guest authoring, etc. The technical side of TrackBack is very simple: when you want to notify a remote site of your existence, you send a ping to that site. The format of these pings (simple HTTP GET requests) is discussed [here]. In the Movable Type implementation of TrackBack, we've added password protection to category pings, IP banning, automatic RSS output, and email notification of new pings.

In other words: we want TrackBack to benefit, and to be useful to, more than just Movable Type users. We want to encourage integration of this feature into other weblog tools; that's why we have documented the ping format below and have tried to make the basic framework very simple. Feel free to email us (trackback@movabletype.org) if you have questions.

Looks like I won't be getting to bed early tonight! More to come.

Sam Ruby reponds to my earlier post: WSIL is decentralized unlike UDDI... this means that adoption will be based on the network affects model. Hopefully the existence of a royalty free, open source implementation will help "prime the pump". Let the "effect" begin!

CNet is reporting that IBM has donated a Java implementation of the Web Services Inspection Language (WSIL) to the Apache Project. This is great news that I hope leads to more discovery of its potential uses as a better means for the publishing and discovery of Web services today.

I've been keenly interested in the WSIL specification for sometime because it represents a more practical approach for discovering Web services today then UDDI. It has been well documented that UDDI has some significant issues from attempting to be too grandiose and thereby maligning its true purpose. Should we be focusing our attention on WSIL rather then UDDI? I think so. Let me explain.

UDDI is a specification for a registry server where service providers can publish their identity, classify their offering and provide technical information for service consumers to bind to a service. There is a collection of XML formats for storing the different record types in UDDI that can be accessed with a SOAP API.

WSIL is a relatively simple XML file format that is published with a standard URI on a provider's web site and read by consumers to discover and use the provider's listed web services.

Without noting their details, the difference between UDDI and WSIL are subtle. In comparison to WSIL, UDDI is significantly more complex (multiple XML formats and an API) and requires more overhead (server software) to be implemented. WSIL is a lightweight and decentralized mechanism for discovery of Web services.

WSIL assumes the service consumer has found and at least knows the provider -- perhaps they have has established a business relationship through traditional means. In reality, most business partners today do not find one another in a registry, and it is unlikely that they will replace negotiating agreements with automated ad-hoc means. (For a more in depth comparison of UDDI and WSIL read "WSIL: Do we need another Web Services Specification? Explaining the difference between UDDI" by Tarak Modi.)

In a lot of ways, WSIL is quite REST-ful[1] in nature -- its like RSS for Web services. RSS is a file format with pointers to published content that can be syndicated and aggregated. WSIL is a file format with pointers to published Web services that can be discovered and bound.

Its also far less resource intensive which is important to lowering the barrier to adoption and broadening the potential uses of this information.With Web services capable of being published and discovered so simply, new uses of WSIL and novel services would likely develop that could further diminish the need for UDDI in its current form.

This is an exciting possibility to me that I think deserves more attention. WSIL offers a more practical and lightweight approach to an area that needs a better answer if Web services are to proliferate. IBM's donation to the Apache Project is helpful in furthering WSIL's potential. More support is needed in other languages and tools and more importantly recognition by the standards bodies.
---

[1] I'm not a devotee of REST, but I think it makes some good observations that should be noted by the Web services community.

As a follow-up to my post last week I thought I'd point out that last week ZDNet published a special report on Bluetooth. For those of you interested in learning more about the technology these articles are an excellent starting point in addition to those I shared in my previous post. (Except for that tabloid piece from Reuters, of course.)

Here is a follow up to my previous post on this topic. ZDNet ran an opinion piece ("Dick Tracy rides again") on the potential of electronic ink technology.

CNet published this article today detailing Gartner analyst Mark Driver's research that conversions to Microsoft .Net could run roughly half of the original development costs.

Ari Bixhorn, Microsoft's product manager for Visual Basic.Net, disputed Gartner's conclusions. He said most conversions to .Net are about 95 percent error-free, meaning they can be completed at a cost much lower than what Gartner estimates.

Gartner, however, considered factors other than code conversions in its analysis, such as training and lost productivity. Bixhorn said he didn't see either training or productivity problems as much of a concern.

I take research with a healthy dose of skeptism, but I couldn't pass up calling attention to this quote. Training and productivity problems aren't much of a concern? Come on! Could you at least try and come up with a better response?

I've long felt that personal area network (PAN) technology was a good idea that had a place in the marketplace, but I've been discouraged by all of the problems Bluetooth was plagued with and the lack of hardware support. Judging by the press stemming from last week's Bluetooth Congress & Expo 2002 in Amsterdam, the momentum could finally be mounting, but its success is long from assured. Issues of education, implementation, usability have yet to be addressed in addition to developer and user adoption -- the ultimate determining factor.

I think it is absurd to think Bluetooth and Wi-Fi (aka 802.11) are on a "collision course" with each other as this Reuters news article suggests. Besides trying to stir up some non-existent controversy, the article also glosses over the more interesting properties of Bluetooth technology to create personal area ad-hoc networks in favor of its more mundane cord replacement usage.

There are certainly similarities and a bit of overlap between Bluetooth and Wi-Fi, but they are clearly complimentary wireless technologies. Generally speaking, Bluetooth is to peer-to-peer as Wi-Fi is to client-server.

Bluetooth is focused on enabling ad-hoc networks (also called "piconets") of nearby devices in a low powered lightweight low-cost form factor. Unlike infrared beaming made popular by the Palm Pilot, Bluetooth enabled PDAs could transfer files and information without "seeing" each other and at greater distances. More far reaching prototypes include a pen that transfers your writing to a PC. As long as you have two bluetooth enabled devices you can form a network even if its in the middle of desert or on-top of a polar ice cap. (For more in depth technical information on Bluetooth see Embedded.com's "Bluetooth Basics.")

Wi-Fi was designed to provide a wireless alternative to LANs with greater range and capacity (also greater power consumption) by utilizing centralized antennas connected to wired line networks. Interestingly Wi-Fi is also being adapted into a means for community broadband networks and public "hotspots." Irregardless, setting up a Wi-Fi network requires advanced planning and a structured implementation with stationary coverage.

So there is no controversy or "collision course." Bluetooth and Wi-Fi compliment each other by offering contrasting feature sets that enable developers to choose the appropriate means to wireless communication. Though Bluetooth's acceptance is not as assured as Wi-Fi's, I'm hoping the industry moves quickly to establish closer and more seamless ties between the two in the future.

In "Colin Moock on Flash MX" Richard Koman interviews the author of O'Reilly's ActionScript: The Definitive Guide. Moock really nails what I've been talking about with Flash -- its more then just a vector graphics and multimedia platform, but rather a means of developing and deploying lightweight cross-platform Internet applications.

I am convinced that the emerging service-oriented Internet will necessitate such a platform to compliment the document-oriented web browser. Moock agrees: "Flash is a loud message to everyone who is working on standards: this is obviously a need, so maybe it's time to pay attention to this kind of content."

This is encouraging to see, but we're a long way off from this notion gaining the support it needs to thrive.

Joel Spolsky doesn't post very frequently, but when he does I always enjoy the clarity and insightfulness his writings brings to a relevant topic. His latest post "Strategy Letter V" is no exception.

In this post Joel debunks many of the myths, oversights and misconceptions of free software economics on the industry by first pointing out how "smart companies try to commoditize their products' complements." He then goes on to demonstrate how commercial technology powerhouses such as IBM and Sun are putting free software to this use.

Boing Boing's Cory Doctrow comments positively, but points out that Spolsky's criticism of Sun's "strange" and seemingly scattershot market approach of supporting write-once-run-anywhere software (Java) is mistaken. "Sun's unique sales proposition is what it has always been: interoperability," says Doctrow.

I have to agree with Joel somewhat that Sun's rhetoric and actions seems more focused on undermining Micrososft then developing their own business. However Sun has been at that game for years and has continued to be relatively successful in the commercial space by supporting free software and advocating Java. (Whether Sun's success will continue is another issue in light of a tough economic climate and mounting competition from IBM and HP to name a few.)

I think there is something more subtle to Sun's actions then then Joel's assertion that "...Sun is a hardware company. Making hardware a commodity is the last thing they want to do." I do believe that Sun does not want their servers to become a commodity. I also believe that interoperability is certainly one as Cory points out, but what is not been brough up is the timing of Sun's release and support of Java. When you look back, Java came at a time when Microsoft's dominance of all computing systems was almost unchallenged with Intel hardware in toe behind it. Generally speaking, there seemed to be little advantage or momentum for Unix based systems.

Riding the emergence of HTTP, HTML and the browser as a publishing platform, the Java platform changed that (after one false start with applets) by providing a better economic and technological solution for server-based computing solutions in the enterprise. Given Sun's mainstay has been its powerful servers that outperform and provide more reliability than Wintel solutions, shifting the momentum towards the server makes all of the sense in the world.

Now that Java has contributed to this shift that benefited Sun, they cannot simple drop support for Java as it would be irresponsible and bad form. Yes, IBM, HP, and Dell amongst other hardware vendors can run Java applications on its servers, but they where slow to react and now that they have they're playing in Sun court and not down the street. I presume that Sun was betting that they can engineer better hardware and provide better service to its customers with better economic opportunities for system integrator and resellers then those companies. It was and continues to be a risky game, but in my experience Sun has succeeded and is poised to continue to do so with IBM and HP continuing with their plan to grow larger and more lethargic as one-stop-shopping megavendors.

As I initially suspected the Alexis de Tocqueville Institution (ADTI) whitepaper was FUD and poorly written FUD at that. In a recent essay Anthony Awtrey reports that the paper was pulled and significantly revised to address a number of incorrect statements and flawed arguments before being reposted. ZDNet's eWeek covers the release of the paper here.

I'm not alone in blogspace in my admiration of The Pixies. Mena "Movable Type" Trott writes about her memories of the band's Doolittle LP. I knew there was a deeper reason why I like Movable Type so much.

According to CNet a startup named E Ink recently demonstrated a .3 millimeter screen (the thickness of a credit card) using "electronic ink." The method does not require backlighting nor does it require additional power once its image is setup. This could really be useful in designing mobile devices with better battery life. The approximate cost the technology would add to a device was not disclosed. Sadly the technology is not expected to be available on the market till 2005. It would also seem that black and white (perhaps greyscale?) is only supported. I'm a RIM Blackberry user so I don't care really. What I would like are large eletronic ink screens that I can hang on my wall and wirelessly update the images. Then I'd care about color.

Jon Udell: "Call me an extreme anti-extremist. Call me a bundle of contradictions. There's more than one way to do it. I'll never sign up for a methodology, no matter whose. But I'll learn what I can from all of them."

Meg Hourihan article "What We're Doing When We Blog" does an excellent job of defining what weblogging is all about and what makes it unique and special in comparison to other web content. I've read a lot of definitions and discussions of what is weblogging, but none of which I felt nailed it until now. I particularly liked her refrain from any emotional rants while focusing on the format of weblogs rather then their the motivation and content.

Mozilla could be developed into an application virtual machine[1] for delivering lightweight easily scripted applications over the Internet. Last week's release of the Mozilla browser got me thinking about the possibilities. Recently I've been exploring Flash's ability in such a role because it is more then a vector graphics and multimedia tool and its the most mature and widely deployed engine that could fit the job. It is worth considering how to leverage the Mozilla communities work to support such a platform.

David Boswell in his article "Mozilla as an Application Virtual Machine" over 2 years ago raised the notion of Mozilla potential. At the time Boswell focused on Mozilla's strong cross-platform code base as the means for such a function. To some degree he is correct. XUL allows developers knowledgeable in XML and Javascript to modify and enhance the Mozilla browsers function. However the development of non-browser applications is limited to knowledgeable C++ programmers willing to learn the internals of the Mozilla project's work first. While the project's work is yielding these types of applications, it either excludes or burden most others from participating and benefiting to a larger extent. This is fine for some, but is unacceptable overall.

The Web browser has and will continue to serve us well. Mozilla is the best browser yet. My experience using it full-time since release candidate 1 has been nothing short of superb.

As the Internet continues to evolve into an "Internet operating system" of programmable interfaces, ubiquitous access and distributed computing resources, the document-centric browser is an awkward solution to a growing number of emerging needs. The browser is not dying by any means -- it just needs a mate to compliment it.

This compliment would support an open cross-platform means of easily developing, deploying and running applications. Ideally it would make use of the same standards and technology utilized by web browsers. These web applications would be easily "streamed" over the Internet and executed locally rather then on a server. As a former Visual Basic guru from back in the early 90's, I envision this Internet application virtual machine to do for Internet applications what the Visual Basic runtime engine did for Windows application development. I initially referred to this as an "application-centric browser" because this platform shares many of the same properties and core technologies and fuses them with an application framework engine.

Here is a cursory look at what core elements that are already available through the Mozilla project that could be utilized in developing such a platform:

• The ability to script logic with Javascript.
• Graphical display using HTML and CSS.
• Data handling through its support of XML, XSLT and DOM.
• User interface design through XUL.
• Basic Web services support via SOAP and XML-RPC. (Perhaps more is needed though.)
• Vector graphics support using SVG. (Native support is coming.)
• A component API for creating plug-ins when necessary.
• Packaging capabilities using JAR (however this function is currently limited to the browser skins and would require some adaption)
• Network installation capabilities using XPI archives.

This is a strong base for developing an Internet application virtual machine, but more is still needed:

• Better forms support. Existing HTML forms support comes up short requiring XForms support.
• A lightweight web application server for supporting peering, messaging and the dynamic generation of local displays. (Userland's Radio is a prime example. KnowNow's technology is also worth noting here.) Some of the functionality already exists to a degree, but could probably use additional refinement and functionality.
• An application manager to handle environment functions such as streaming, upgrades, uninstallation, managing tasks and security.
• A security sandbox to prevent buggy or malicious applications from doing damage to the local system. Mixing easily downloaded applications and given them access (however limited it may be) while risky, is necessary in order to be useful.

In some respects the open sourced SashXB for Linux and its closed source Sash for Windows is quite close in many respects. (Incidentally some of Mozilla's code is used in SashXB.) SashXB is not nearly as cross platform and lacks some of the above feature list such as a built in web application server. I won't be able to go into a full comparison here.

Mozilla has most of what it takes to be the foundation to an Internet application virtual machine, but some additional work and assembly is required. The extensive open code base and its adherence to standards makes it an ideal candidate to create an application-centric compliment to its browser. In order to move forward the need for such a platform must receive wider recognition in the Mozilla community and a focused concerted effort initiated.

--

[1] In recent writings I've referred to this concept as an "application-centric browser" for lack of a better term, but given Mozilla is a Web browser I'm refraining from using the term to avoid being too confusing. I still am in search of the "perfect" term for what I am thinking.

"SWF is Not Flash" by Jacek Artymiak and "SVG On The Rise" by Dean Jackson are contrasting articles on the SWF (Flash) and SVG formats that, while both are well articulated, fail to highlight what truly differentiates the two formats.

Artymiak piece is well articulated in pointing out some misconceptions of the SWF format and offering valid arguments in its defense. Jackson's rebuttal piece is equally as articulate in bringing to light some important facts on the implementation and adoption of SVG and making further clarifications on Artymiak's piece.

I found myself siding with the SWF format. This was somewhat surprising to me since I tend to favor open source and open standards. However in taking a step back and looking at the larger picture, I felt SWF currently provides a better solution overall.

> SWF is more then just a vector graphics and animation format. Comparing SWF and SVG is not apples and oranges, but rather apples and a fruit basket. Through recent iterations, SWF can support embedded forms, script, user interface components and XML feeds. While the ability to embed SVG graphics in XHTML files and read view the source is attractive, in order to match the capabilities of SWF, SVG needs to be combined with other specifications and technologies such as SMIL, ECMAScript to name a couple.

> Artmyiak points out and Jackson admits that SVG et al are lacking an integrated mature development tool like Flash. While many tools have added (or will) SVG support to their software, this does not match the depth, sophistication or ease of use that SWF tools like Flash provide. Remember, graphics are usually (and should) be done by designers and not coders.

> Jackson's arguments did not address users, but were very focused on the SVG advantages for developers such as the ability to view source and better integration with existing web technologies. I'm a developer so this does appeal to me in comparison to SWF, but I kept asking myself what about users? What advantage does SVG provide users that SWF does not? Will a user care that they can read the code or that it integrates better with existing technologies? Why should they download a SVG plug-in? In this context Jackson's pro-SVG arguements is lacking and flawed.

These points stated, I continue to be disappointed that so much of the recent debate has been on the multimedia, particularly vector graphics, capabilities of Flash. The argument of which is the better vector graphics or multimedia platform is increasing one of splitting hairs as the two will become essentially more similar over time.

As I've said before, the more important point and key differentiator of SWF and Flash is its added ability to deliver lightweight yet rich applications over the Web. In recent releases the format has added integrated scripting, forms support, XML streams support and user interface components. Here the standards driven space presently lacks an answer or focus that I wish they'd spend some time.

I loved paying homage to The Pixies in my own special way, but after trying the "where is my mind?"[1] tagline for a week I decided it wasn't working of me. Looking back my first dozen or so posts I thought "thinking outloud" summed it up.

I've also posted my "professional" bio for anyone that wonders what my background is.

[1] "Where is My Mind?" is track 7 on The Pixies Surfer Rosa/Come on Pilgrim disc -- one of my cannot-live-without rock albums of all-time.

Richard Monson-Haefel points out a well articulated piece "Who Cares About UDDI?" by David Chappell. Like Richard, Chappell does an admirable job of summarizing some of my misgivings with the UDDI specification. When I wrote my last paper on the practical uses of Web services the issues I was astounded that the UDDI was unilaterally supported as part of the "holy trinity."

UDDI seems much too grandiose and misses its true purposes. If you look at the timing and the originators of the initial spec you get the specification you get the suspicion that they may have still been drinking the B2B marketplace kool-aid. (Herein lies the problem of close specification design that is becoming all to common.)

I agree with Chappell that UDDI doesn't offer much value at present. However I disagree that a central directory services have little value until and if dynamic Web services become common place. At a minimum a directory will help large distributed organization manage, track, organize and maintain the presumably hundreds and perhaps thousands of Web services that will appear behind their firewall and with its close business partners. Given the IT hairballs I've witnessed this could be very valuable. Discovery is also another important aspect to these directories. It is not uncommon for one part of the organization to not know what another is doing that could be useful to them. If implemented and maintain properly I think the directory could resolve many of these disconnects. Does UDDI do any of this well in its current state? I think not.

I'm glad to see someone else noting WSIL (Web Services Inspection Language) as I did in my paper. WSIL, while developed as closed specification by the shadow specification organization call Microsoft and IBM, is more useful and requires less overhead to implement in achieving a similar results to UDDI. WSIL in a lot of ways is quiet RESTful in nature -- its is like RSS for Web services. For more of and in-depth comparison of WSIL and UDDI I recommend Tarak Modi's "WSIL: Do we need another Web Services Specification?"

I've been quite curious as to why I have not heard more noise about this seemingly useful specification. Maybe I'm missing something and need to dig further.

Steve Aglin: "I have not doubt that some of Qualcomm's woes come from (supporting BREW), and may have impacted the acceptance and sales of their cell phones in the market place. Perhaps, it's time to consider the adoption of J2ME where there are many more developers, solutions, and application implementations including productivity tools and games for its cell phone users. Just a thought."

Right on Steve.

Incidentally Sun's proclaimation of BREW being flat yesterday had a purpose. Qualcomm was to announce the release for the first major upgrade to BREW later that day.

I feel like an official member of Blogspace now. I got my first backlink today.

It been documented that using your browser as a writing tool has its limitations and is painfully lacking in some respects. Jon Udell has covered this better then any one else in his article on the universal canvas. Jon sums the issues up nicely in his review of Radio 8:

Part of the answer is a ubiquitous replacement for the browser's hopelessly primitive TEXTAREA widget. The Microsoft DHTML edit control, exploited by Radio and other web-writing systems, is a flawed solution in several ways — IE-only, producing HTML rather than XHTML or XML. But the fact is that for the 90 percent of users who are running IE browsers, it works well enough — and (to my taste) better than the Java-based alternatives I've tried.

I've been painfully aware of this myself as a developer of several content-oriented sites. I'm also reminded of this shortcoming as I write this post in Notepad because I find the TEXTAREA interface of MovableType too difficult. (There are desktop applications such as w.bloggar or even Radio that make this easier, but I'm a fairly transient person I often find myself at a machine that is not my own.) Like Udell this has lead me to be on the lookout for a better solution.

This search has lead me to consider the possibility of using Flash. Flash 4 added forms support. Flash 5 added XML support. With MX, the latest version of Flash, Macromedia has added interface components and more robust scripting. With these new features and its widespread deployment across multiple OSes and browsers, I theorized that a replacement component may be possible. Just I recently came across Stuart Schoneveld's promising Rich Text Editor that seems to validate my theory. There is no source or documentation to know to what extent the control could be pushed but I find this encouraging based on my cursory knowledge of Flash.

This find has lead me to consider the possibilities of having an extensible editor component that, I think, could potentially bring in-browser authoring to a new level. With the use of an XML configuration file an application developer could create a in-page editor that are specific to the writing task and obscures the user having to understand the semantics of the underlying markup. A user would not have to be bothered in knowing that a title string should be centered, bold and blue or encapsulated in a <span class="title"></span>. They would just have to select the string and select title from the editor's tool bar. The editor would handle the translation. That would be very helpful.

CNET reports Sun is claiming victory for Java on mobile phones (via J2ME) over Qualcomm's BREW technology in the space.

I recently made similar comments on slashdot.org in a thread on mobile gaming platforms and reposted it here.

The article does not mention another potent advantage of J2ME: it is intended for many types of devices other then mobile phones like BREW. J2ME is not "write once, run everywhere" because of obvious differences in the varying interface, capacity and uses of such a range of devices. A significant amount of code reuse can be achieved if applications are developed properly.

J2ME still has its issues to work out and developing cross-device applications will always have its challenges. Technicalities aside, Sun has developed the right business relationships and models to gain widespread support and allow J2ME flourish. I expect this momentum to continue while BREW struggles and eventually withers on the vine. Its not the superior technology that wins out, its the one that has the widest range support. For instance, Betamax vs. VHS.

There are those who disagree with me, but they can enjoy their every last bit of performance in obscurity.

CNET reports that Macromedia announced a partnership with Web usability expert Jakob Nielsen to develop guidelines for developing Flash-based applications.

Nielson has been a harsh critic of Flash and rightfully so. Back in March when Flash MX was released I wrote "Unfortunately most graphic designers I know seem to lack the common sense to save their artistic ambitions for the gallery and not my screen when I'm trying to get something useful done. I wish there were a standard to do something about that." I'm pleased to read that in some sense it will.

When Macromedia released this latest version of Flash, they raised the ire of standards and open source advocates alike for suggesting that web sites be designed entirely in Flash and not supporting related open standards such as SVG and SMIL. I weighed in that there is a growing need for a "standard" lightweight environment for developing and delivering applications and that Flash MX attempts to address it. Whether Flash is the best or right solution to addressing this need is open to conjecture.

The Web browser serves its purposes as a very useful and vital tool to making the Internet work, but it's an awkward way to deliver true application functionality. In mobile computing where function is valued over content, we've already seen the general failure of browser-based solutions (WAP) and rising interest in J2ME applications. This is why I'm convinced that an application-centric "browser" is needed to best utilize the emergence of the programmable Internet via Web services and advance the function of the Web as we know it.

Not to miss out on all of the fun and excitement I've added the recommended tags for RSS (newsfeed) linking and a "blogroll" of the weblogs I scan in sidebar.

This is the part of Internet I marvel at. Four days ago Matt Griffith made a suggestion for sites with RSS feeds to add a so aggregators like Aggie tool can automatically discover a news feed. Mark Pilgrim latched on it and got several news aggregators to follow and presto! The "spec" has already gone through a revision.

Adding a "blogroll" to my home page identifies which site I find interesting and important that may also be of interest you. This serves a more interesting purpose which is being explored -- social networking. By taking these links and comparing them to others in addition to other sources such as Google or Daypop, automated services can be developed to expose interesting patterns, identify "hives" of like-minded people and other bits of surprising information in real-time. This is really interesting stuff that could lead to some interesting approaches to knowledge management and collaboration.

On a aside: Blogroll? Yick. Who comes up with these names anyway?

In response to a slashdot.org post regarding a CNN article mobile gaming and Qualcomm's BREW technology, I made this one of my own:

Many of these types of games and more where being demonstrated on JavaONE this year on J2ME devices so I would get too hung up on BREW. In fact I wouldn't even bother with that technology.

BREW is currently a CDMA only technology. The majority of the world uses GSM thought. (Americans sometimes forget this since CDMA has a larger, but weakening, footprint in the US.) The majority of carriers and handset manufacturers are committed to J2ME in someway. Motorola has gone so far as to pledge that all of its phones will ship with J2ME by the end of this year. Even CDMA carrier Sprint PCS have decided to forego BREW for J2ME [sun.com] when they launch thier new service this August.

If your a developers, where would you put your effort first?

J2ME has its limtiations though. Then again so do these devices -- With a screen not much larger then an airmail stamp we're not even talking game boy here. The limitations of J2ME are currently being addressed with initatives such as Project Monty [sun.com] (a new high performance virtual machine), Mobile Game API [jcp.org] and the Mobile Media API [jcp.org].

Carl Zetie discusses the unresolved issues and hurdles for Web services in mobile application with his article "Don't Hold Your Breath For Mobile Web Services."

I'm glad to finally see this recognized somewhere in the mainstream press. Its been on my mind for months now.

I differ with Zetie in only a few areas:

> I am more pessimistic to whether WSDL and UDDI have a place at all in mobile applications and WANs. Given the low powered nature of most devices in the foreseeable future and the issues of cost and network latency, I believe a less dynamic and more tightly coupled approach to mobile applications will be more appropriate. Dealing with mobile application updates will be marginal given the miniscule file size and the ability to install applications over the air. The ability to process WSDL and UDDI consumes processing power and battery life (a key concerned often overlooked) in addition to adding to the size of the application code.

> I am not as convinced that 3G networks are going to resolve as many issues as many such as Zeite suggest. Perhaps in theory 3G networks will. However carriers are charging subscribers based on bandwidth consumed thereby putting the onus bandwidth conservation on developers. Consideration also needs to be given to the potential worse case scenario of saturated mobile networks.

> I also think more attention could have been paid to the need for asynchronous Web services (messages queued and sent once a connection is available) versus synchronous Web services ("real time" request and response) that are commonly thought of today.

My concern is that the optimism in 3G networks and the more powerful devices will yield less streamlined or even bloated specifications that do not make economic sense and are simply not useful. Stay tuned.

The O'Reilly Network published "My Blog, My Outboard Brain" by Cory Doctorow of Boing Boing fame on how he finds his weblogging an indispensible tool for managing information and knowledge.

There has been quite a bit of discussion concerning the use of weblogs in the realm of knowledge management. Just persue through John Robb's weblog or the k-logs (knowledge weblogs) mailing list for more. This dicussion has been drowned out of late by the ongoing debate and sometimes flame war over the impact of blogging on professional journalism.

For sometime I've been considering the notion of using a weblog for managing my own information better. Like Doctorow, I am an "infovore." I consume six times my weight in information. My workstation is commonly litered with bookmarks and my desk reams of whitepapers and news articles. I intend to find out how this tool can help me and presumably others.