January 2003 Archives

(Sorry for the NY Post-style headline.)

Jason Kottke makes a very good observation: most aggregators are misusing the HTTP referer field. He notes that 6 of his top 10 refers are from aggregators. Doing a bit of digging through the specifications he notes:

The definition of referer from RFC 2616 on HTTP 1.1 seems relevant to the question. It states that The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained and that the Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI.

Good work. I have found this annoying and now I have a reason to complain. (For the record my RSS plugin does no such thing.)

In taking all of the recent discussion and experimentation with TrackBack and related interfaces, I thought it would be helpful to draft some suggestions for consideration for the next generation (NG) of the interface. This document and forum (more on that later) is meant to be a starting point to begin a productive discussion and further the constructive and valuable work being done thus far.

Since its introduction in June 2002 by Ben and Mena Trott, TrackBack has been gaining momentum as a means for creating distributed forms of communication, intertwinularity, manufactured serendipity and other social networks. In recent weeks experimentation and discussion of the interface has been catching on. With this, some of the shortcomings and limitations of the current specification (v1.1) have begun to come into focus.

The specification document need more clarification and refinement particularly as to where the specification ends and specific implementations begin. Additionally the specification would benefit by better addressing issues of extensibility and the reasonable expansion of its scope. These are some of the more specific proposal I have collected.

Make TrackBack even more RESTful. The original intention of the interface is to comply with the REST style of architecture. Version 1.0 did not fully comply with this stated goal and necessitated the release of version 1.1 (with the help of Paul Prescod) that brought it closer, but not completely, into compliance. The next version should continue down this road towards complete compliance. To that end:

• TrackBack should utilize standard HTTP messages for all replies (201 Created, 200 Success etc.) and depreciate the proprietary messaging scheme currently implemented.
• Content negotiation (conneg) should be supported in addition to the query string switch currently in use. The query string switch would take precedence.
• In addition to the application/x-www-form-urlencoded MIME-type, TrackBack should alternately accept an RSS item fragment with a text/xml type, in the body of a POST.

Forge even closer ties with RSS. TrackBack already share a very close relationship, but more can be done them even closer together. I've already disclosed as one in the previous section. Other considerations include:

• Implement RSS field names and depreciate existing field name. excerpt would become descriptpion. url would become link. blog_name would become dc:source.
• Establish required fields for POSTs that coincide with the RSS 0.91 specification, the most widely deployed version of the format. In other words title, link, and description.

Refine and expand auto-discovery options. Works fine though criticisms around that this is a hack and break standards compliance. The current practice isn't terribly efficient or plausible for more sophisticated uses. this area requires further discussion. Here are some cursory ideas.

• Use RSS structure instead of RDF. If TrackBack where to adopt closer ties with the RSS format as I have suggested this only seems to make sense. I'll just stop there with this one.
• Similar to RSS auto-discovery, TrackBack should make use of the link tag to assist TrackBack client in discovering the URI associated to a web page. (Assuming HTTP messages are adopted, the 201 Created message returned to a successful ping should also return an RSS item fragment with all the pertinent meta data usually recovered extracted from the existing method. An alternate take would use the link tag to point to an external file containing the RSS Item fragment. Yet another would be a hybrid of the two where Dublin Core tags are embedded in the HTML.
• Specify the discovery and function of an optional TrackBack information service. The main purpose of this service is to make auto-discovery more efficient and scalable then grabbing an HTML page and scraping it. (Obviously there isn't enough detail here yet.)

A couple of other facets that should be addressed include:

• Multiple Pings per web page. Outlawed? Permitted, but not advisable? Just fine?
• TrackBack Ping ID guidance. There seems to be some confusion here and could use further clarification and refinement.
• FOAF and digital signatures. Should the concept be worked into the specification?

I've also created a forum to more directly discussing these proposals and share ideas. This is a bit of a first in more ways then one. I've been using TrackBack here since almost day one, but have never used comments to experiment with them. (I've begun subtly tinkering with how MT's comments work to do something different then how they are commonly used.) Alas, I did not get around to following my own advice and implement comments AS TrackBack. Soon I promise.

Another place to discuss this and similar topics is the ucapi-discuss (Universal Canvas API) mailing list hosted by Yahoo. All encourage you to join, ask questions and participate in the discussions.

This is a list of resources and posts on the topic of TrackBack that I've collected recently. Its by no means a complete one. (Please don't be offended if I missed you.) In no particular order:

• TrackBack Technical Specification
• The TrackBack Development Weblog
• Cohesion (Sam Ruby)
• The universal canvas and RSS apps (DJ Adams)
• Trackback in the saddle again - a list of various TrackBack variants and implementations. (Ben Hammersley)
• XML::TrackBack
• Comments via TrackBack (Rael Dornfest)
• Mark Paschel's TBPY -- a standalone TrackBack CGI written in Python.
• TrackBack for Notifications (Scott Andrew)
• Whitepaper: Pingback vs TrackBack 1.1 (Ian Hickson)
• RESTLog Comments API (Joe Gregorio)
• Ridiculously Easy Group Forming
• Centralized TrackBack Aggregation for News and Links (PopDex)

More noteworthy thinking in the realm of TrackBack and simple RESTful interfaces. Scott Andrew writes:

I think, eventually, the TrackBack notification format should supplant the weblogs.com ping format. Why? Although weblogs.com sports a plain vanilla HTTP POST interface, the implementations in weblog software are overwhelmingly RPC-based. This is not as good as it could be, because it means that endpoints other than weblogs.com need to use XML-RPC libraries to parse incoming pings.

And for what? Two lousy pieces of data. Compare this to the POST-based TrackBack format and the far richer data it contains.

I agree Scott. This is an excellent demonstration of the issues Sam Ruby and I have written about. Its also another potential use for the concept of TrackBack and its versitility.

Scott continues:

But a TrackBack isn't the same as an update notification. TrackBack creates a relationship from one post to another post on another weblog, or posts across categories. To my knowledge, no weblog software emits a non-contextual, TrackBack-compatible update notification.

This is partial true in that weblog software currently does not support said behavior. That said it doesn't have to be that way. Using XML::TrackBack it would be trivial to create an application. (Is this a LazyWeb post is disguise?)

Via Phil Ringnalda I've happened upon Mark Paschel's TBPY. Mark explains:

TBPY is a Trackback server CGI for the rest of your site. Rather than accepting pings for numbered weblog entries, it accepts pings for pages of your static or dynamically generated web site. Invoke TBPY through SSI to include your pages' Trackbacks and the appropriate RDF for automatic Trackback discovery, or include the RDF (static) and Trackbacks (through RSS files) yourself.

Excellent! This is exactly what I meant in my posts to the Blogger developers list earlier this month. It also demonstrates PingBack advocates criticism of TrackBack requiring a seperate ID as flawed as I stated in this recent post.

Interesting developments continue to unfold.

I was pleased to find a copy of Programming Web Services with Perl by Randy J. Ray and Pavel Kulchenko in my mailbox Friday evening. (Thanks Paul!) I've given a quick scan and its quite well done and quite thorough. I'll be posting more details comments in a later post.

One quick highlight and the first chapter I went directly to and read was Chapter 11 which covers REST. (This may be a first!) My first imprlession is that its well done and covers all of the basics from theory to analysis to a basic implementation scenario. It does a good job of taking the scientific definition of REST and putting it into practical terms. It covers all of the basic methods and their usage and even discusses aesthetics of URI design. It's criticisms of REST are fair though a bit tough. I would have liked to have seen a bit of discussion on comparing SOAP and REST (the book explictly avoids it) particularly in discussing the advantages of document-centric approach to Web services that REST promotes. It would have balanced the chapters criticisms of REST and make it more neutral.

Just some initial thoughts as a highlight to my commentary to follow.

Sam Ruby continues his patient evangelism and has released a new essay entitled Evolution of the Weblog APIs that is a follow up to a blog entry posted over 8 months ago. The MetaWeblog API has since evolved with the introduction RSS 2.0, and this lead to a new RFC. My questions on that RFC have gone unanswered, and I have expanded upon them in this essay.

Sam's essay includes a detailed demonstration of the limitations and short-comings of XML-RPC and how ugly it can get trying to extend it. In the essay Sam details an XML-RPC request that is 43 lines of copius XML-RPC tags to express and translates it to 8 lines using HTTP headers and RSS.

Its black and white arguments like these that made me lose favor with XML-RPC and the like and develop RESTful leanings. REST architectural principles combined with SOAP or RSS are remarkably simple, elegent and extensible. Especially when you are prepared to cope with change. It puzzles me that anyone can still insist that XML-RPC is somehow simpler or better suited.

Hilary Rosen is resigning her post as the head of RIAA and poster child for all things wrong with the music industry. I can just see the ad in the classifieds for this one:

WANTED: Motivated, dynamic individual to lead an extremely unpopular and unreasonable industry organization. Will be responsible for overseeing well-financed heavy-handed attempts to undermine innovation, changing market conditions, and the public domain. Must demonstrate a willingness to thanklessly protect the cushy egotistical existence of industry executives and absurd profit margins gained from bleeding of consumers and the suppression of artists and creativity. Must be able to make unwavering absurd statements, arguments and other forms of verbal cow dung with a straight face at all times. Experience in creatively distorting ("spinning") overwhelming contrary market data a must have. Previous experience working for Microsoft's marketing, public relations or legal teams a plus. Applicants with a conscience or shred of honor need not apply. The ability to operate without sleep at night is helpful, but not required. Applicants are requested to submit an essay not to exceed 1000 words on the topic of why consumers are clueless and ignorant bunch of pirates that are destroying free markets. Resumes can be submitted to poor.us@riaa.org. Please do not call. Due to the high volume of submissions expected, we will not be able to individually respond to each submission. Don’t contact us, we’ll contact you.

The latest of Mark Pilgrim's Dive Into XML column is out. This month covers the topic of coping with invalid XML disguised as RSS feeds without an XML parser. Before you get too excited Mark concludes:

Hopefully we're trying to use a real XML parser first and only falling back on this messy regular expressions-based sgmllib parser when that fails. However, in flagrant abuse of all things pure and sacred, I have managed to extend this script into a full-fledged parse-at-all-costs RSS parser that supports all the advanced features of RSS, including namespaces. It even handles exotic variations of RSS 0.90 and 1.0, where everything is explicitly placed in a namespace (even the basic title, link, and description tags). I don't recommend it, but it works for me.

Mark makes excellent observations as he presents his case and shows that he has the balls to write an article for XML.com demonstrating how to parse an XML-based format without an XML parser. (His words from his weblog.)

At the same time this article is more of the same news we RSS-aware people have already heard. I suppose it can't be reiterated enough.

Incidentally, it was Mark's initial observations on RSS and the release of his ultra liberal RSS parser that lead me into my foray with RSS that still curses me to this day.

I still will foolishly continue to advocate well-formed and hope for the day where only 1% of feeds are malformed.

DJ Adams writes:

It seems that beyond carrying syndication information, RSS is a very useful and flexible way to get all sorts of application data pushed to a user over time. In the same way that a web browser is a universal canvas upon which limitless services and information can be painted, so (in an albeit much smaller way) an RSS reader/aggregator might also find its place as an inbox for time-related delivery of all sorts of information.

Amen DJ! As I asserted in my prior weblog post Web Services We'd Like To See, I wrote Whether it is just assumed or simply overlooked, RSS is the most widely deployed Web service across the Internet. Granted, most RSS feeds have very simple interfaces with almost as simple backends that are unlike the Web services that usually come to mind. (Who says Web services need to be complex or sophisticated anyhow?) Under the principles of the REST architectural style that the Web was built on, RSS feeds do qualify. Consider that any site search engine becomes a Web service if it could emit results in RSS and the format's potential in the realm of Web services becomes more apparent. It is this perceived potential that I've been an advocate of getting the RSS format's house in order.

Numerous instances of the format's value in service delivery are popping up in experiments around the network. Sam Ruby's experiments with automatic linkbacks. Joe Gregorio's RESTful interface for publishing to weblogs. (On an aside, Joe and I are co-conspirators in starting a mailing list to discuss these very notions. Come one, come all.) DJ integrates SOAP and RSS web services in his experimental booktalk application script. Matthew Langham posted in his O'Reilly weblog about the use of RSS in deliverying business data. There is also the on-going discussion of remote commenting and tracking using RSS.

I'm happy to see the message spreading. Today Jeremy Allaire writes in An Explosion of Web Services?:

As I've been reading and writing today I've come to a somewhat obvious conclusion: there's been an explosion of 'web services' in the past year, and it has nothing to do with SOAP, WSDL and such standards as described in the industry but with the ascending role of RSS and RDF as XML data and syndication formats.

Lots of industry analysts have commented that 'public web services' (e.g. web services that can be accessed and used through Internet-accessible public APIs) haven't really happened. When one looks at RSS aggregation sites such as Syndic8.com it's quick to see that there are thousands of "web services" out there for people today.

In an earlier post Jeremy points to some recent thoughts on RSS published by Tim Bray where he outlines some the issues: growing bandwidth consumption, settling on a media-type and eventual demise of RSS aggregators as a standalone application class. He concludes:

...[RSS feed reader/aggregators] just belongs in the browser. It will take a couple of years for it to get cooked into mainstream browsers in a mature enough form to be usable, so the guys with the RSS-reader software should make hay while the sun shines and start figuring out their Next Big Thing.

He also adds anyone who does any kind of publishing software had better start offering a real-easy-to-use RSS interface and sooner rather than later or they're just not going to be in the game.

I think gord says it best when he comments I am so impassioned by this recent explosion in open and well documented interfaces. We are so near a cascade level event with all of the emergent software that is evolving. And each new generation of software raises the potential interactions at an exponential rate. I concur and look forward to where this is all going.

This is a summary-so-far and for posterity to a on-again-off-again discussion that he been on going for nearly a year -- comment tracking and monitoring.

There is a fairly simply solution, comments should be available as an RSS web service and aggregators should be able to subscribe to those feeds on an on-going or trial subscription basis.

Site with comments et al need to provide them as an RSS web service. (They can be dynamically generated or statically -- the implementation doesn't matter.) Some already do this, others could add some form of it quite easily.

Aggregators then need to evolve to support subscriptions based on time and/or activity. (Subscribe for 30 days. Unsubscribe if a new post is not made to this feed for 14 days.) An add-on to this is that aggregators can create groups and sort on them, perhaps even offer an activity log so you know when a subscription has been dropped and so on.

The bottom line is there is no need for a new web app and it doesn't have to be that difficult. Ben Hammersley also sounds off here.

For further reading and the source of this simple genius follow these links:

• http://www.intertwingly.net/blog/836.html
• http://www.intertwingly.net/blog/836.html#c1032609581
• http://www.intertwingly.net/blog/1135.html
• http://philringnalda.com/archives/002225.php
• http://www.syndic8.com/~wkearney/blogs/syndic8/archives/000012.html

I've been under the weather and struggling to remain focused and coherent. The great discussions on the topic of TrackBack and open interfaces carries on.

Ben Hammersley summarizes the various x-Backs being discussed here with a late omission here.

Rael Dornfest put out a call for a discussion script suggestions that I answered. The forthcoming Blosxom 0+7i features a plugin architecture that Rael is currently testing on his site. Rael writes:

A suggestion by Tim Appnel on the Blosxom mailing list tickled a thought I'd had before but promptly forgotten about: Why not use the MovableType standalone TrackBack implementation as a comments system?

Only a couple-three minor tweaks later, a copy-n-paste from my Blosxom trackbacks module, and I have Comments a la Trackbacks! Give 'em a whirl by clicking the "comments" link associated with this (and every) post.

He's testing it on his weblog now. I'm glad Rael liked my suggestion. In essence there is little difference between the two. Sam Ruby agrees. My hope is that these discussions will result in this being abundantly clear and that a more refined standard interface emerges.

Rael's comments implementation based on TrackBack is still kept separate from TrackBack pings. In the comment board for the entry I asked Rael Why differentiate between comments and trackbacks? You're using the same infrastructure, why must the display be different? Combining the two and taking the approach you have you now have a remote commenting API by default. This opens up a whole range of new possibilities. Rael explains that comments was a less then 1 hour hack of the standalone TrackBack application that he didn't want to impact his existing TrackBack database. This is understandable.

Sam Ruby is experimenting with PingBack and has implemented excerpts via RSS discovery. With PingBak becoming more like TrackBack and vice versa, Ben Hammersley points to some writings on PingBack merits in comparison TrackBack. I read these papers when they where released and reacquainted myself with them again. The papers do point out some shortcomings of TrackBack 1.0 and 1.1 that I agree with.

• The specification is too loose and is mixed in with the MT implementation. It took quite a bit of effort by myself to boil it down to what I believe is the essence of the standard. I believe my XML:TrackBack module represents its current state in code.
• Discovery could be made easier and more elegant by storing TrackBack info in a separate file and pointing to is with a <link> tag. (And yes the regular expressions in both MT and the reference implementation are not sufficient bordering on flawed.) Perhaps an optional RESTful lookup service is warranted. the commenting out of ping info is a bit of hack. While I believe in standards compliance, personally I'm not terrible appalled by this. It is easy to implement, requires no additional software and it works reasonably well. Should we improve on it? Absolutely. In due time.
• It would be more RESTful to use HTTP message rather then make up their own. The status messages the TrackBack implementations generate are not terribly helpful to a developer anyway.
• TrackBack does not support arbitrary formats such as images, PDFs and so on. Given the scope and the life TrackBack is taking on, I'm not sure what value supporting arbitrary formats would provide. Something could be implemented with a little modification to the TrackBack core such as alternate ways of auto-discovery.
• While multiple pings in one page can be ambiguous. While permissible it is not a advisable or neighborly practice. More needs to be done to clarify this.

I'm not in complete agreement though as some criticisms are flawed.

• TrackBack does not require an entry to have a different permalink and TrackBack ID. The implementation of TrackBack in MT works that way because of its feature set, but it is not required. A TrackBack ID can be anything including a URI. In other words /cgi/tb.cgi/archive/entry.html is a valid TrackBack ID assuming the implementation of tb.cgi understand how to resolve the path info (/archive/entry.html) to register the ping.
• PingBack is not necessarily easier to install particularly if you don't have an XML-RPC server or access to your servers .htaccess logs. This easecould be implemented with the afore mentioned optional RESTful lookup service. (I would assert that it would be even easier because the need for XML-RPC infrastructure is not necessary -- I admit to having RESTful leanings though.)
• The RDF used by TrackBack is an XML serialization of XML. Any XML parser should be able to parse it once extracted from the HTML. That said it be done better perhaps with RSS instead of purely RDF.

After contemplating these papers, I'm still struggling to see what value PingBack really buys me particularly if TrackBack is refined as I believe it will . PingBack's scope seems far to limited even with Sam's experimental functionality.

What I find puzzling is that the developers of PingBack did not try (to my knowledge at least) and work to improve the TrackBack specification as Paul Prescod and others have. Furthermore, the tone in Ian Hickson's papers seems a bit harsh. (Why?)

What ever the case, this is all very good progress that I believe is leading to a better understanding and cohesion. I'm brimming with enthusiasm for where this is all leading.

Via Boing Boing via Derek Powazek:

Pizza Hut's ad-agency hired Ween to write a hep jingle for its new "cheese-inside" pizza, but Pizza Hut rejected all the tunes they came up with. Ween, who describe the jingle as "one of the best tunes we wrote all last year," has posted it in MP3 to their site.

The tracks can be found here.

I never really liked Ween (bad personal run in), but this would have made a pretty good jingle. Too bad. Maybe it'll show up on their next release?

Sam Ruby has quietly released his latest essay Cohesion. His essay describes some of the currently popular techniques used to promote collaboration and group forming via weblogs. Sam identifies three major approaches (TrackBack, PingBack and Automatic LinkBacks) and briefly discusses their uses in remote comments, creating two directional hypertext links and ridiculously easy group forming.

As is commonly the case, I agree with Sam's assessment. One area where I do give pause is in the phrase via weblogs. There is no doubt this is the most common (perhaps only for the moment) use of these techniques, but I don't believe they are limited to weblogs. At least weblogs in the tradition sense. For instance, what of wikis? How could they benefit from such techniques? Perhaps I getting ahead of myself, but its a valid area of thought to explore at some point.

Sam also raises an issue I failed to mention in my previous post on the topic -- I'll call it reasonable scalability. Sam writes:

Some attempts to visualize [two directional hypertext links such as TrackBack] have tried to impose a hierarchical organization on what essentially is bidirectional, quite possibly cyclic, graph. To date, it appears that this data is too dynamic and distributed to be displayed as such in a static manner except possibly when limited to a single level of depth. A single level of depth also helps the dynamic implementations as it increases responsiveness and doesn't attempt to impose a hierarchy.

Ben Hammersley's experiment with TrackBack threading and MLTFO also illustrates this point.

For all those interested in this topic, I encourage you to join the ucapi-discuss mailing list. Questions by those seeking enlightenment are also welcomed. ;)

Interesting work is afoot in the world of TrackBack and other related concepts.

I received an email from Aaron Straup Cope that he has put my newly released XML::TrackBack module to work. Aaron is developing a OOP-ish interface to the Internet Topic Exchange dubbed Net::ITE.

The Internet Topic Exchange site is an implementation of Ridiculously Easy Group Forming concept. In its current form, ITE is a TrackBack repository with a twist -- participants can create channels that they and others can ping. The integration of a Wiki into the mix, albeit a loose one, is intriguing and one that has yet to be touched upon and explored.

David Raynes has been working on two concepts based on TrackBack infrastructure that he calls ComeBack and Post-It. Post-It allows users to publish whole entries to a MovableType weblog while ComeBack enables distributed comment authoring. I tested both with some basic test scripts using XML::TrackBack. Post-It works without issue. ComeBack uses a slightly different interface that returned an error when pinged. David has now integrated the two in one site achieving a forum-like effect where a user can make a post and others can comment on it.

The notion of a remote commenting interface that ComeBack represents is an intriguing one. This is a topic I will return to in a later post. Too much to write about here. Post-It is not as apparent to me. As a publishing API, Post-It bears a great deal of similarity in principle to the RESTLog API. The value of free-for-all posting that it enables via TrackBack I'm not entirely sure about.

Yesterday, Ben Hammersley was his own guinea pig as he attempted to implement TrackBack threading on his site. Ben had to retreat for the time being and shares his learnings in a later post here.

Sam Ruby recently put a different spin on Mark Pilgrim's automatic linkbacks system by utilizing RSS feeds as its source of excerpts. Sam explains To participate, you don't need to use weblogging software that supports trackback or pingback, you simply have to update your templates to have a link to your RSS feed. In a follow-up post he reasons I actually experimented with mark's code for a bit, but the biggest problem I had was that it looked like it would require continual investment to weed out the ever growing number of portals and personal aggregators. I was also concerned about the feedback loop that could occur given the amount of back traffic I get whenever I mention anything on Mark's page.

Shelley Powers continues to advanced something she calls BackTrack on top of TrackBack information. In this post she explains its purpose In each individual posting page is a section labeled with Sticky Strands and listing all of the TB pings the posting issued. The functionality I added today takes those pings, follows them back to the posted weblog, and then lists all of the trackbacks that weblog posting has received. Sam Ruby has joined in.

Both are excellent ideas that underscores the increasing value (and necessity) of meaningful titles and excerpts.

This experimentation has all been very intriguing and worthwhile in our discovery and understanding of the network and social effects of two-way hyperlinking systems. In reviewing this work I'm beginning to see some emerging issues and topics coming into focus. (In no particular order.)

• Extensibility of TrackBack. How should this is achieved without breaking some semblance of interoperability. For instance, I was unable to make a ComeBack post with XML::TrackBack because email has been added, excerpt renamed comment and blog_name renamed agent. All are required. So a TrackBack enabled tool cannot interoperate with a ComeBack interface, but does it have to be that way? It would seem not if these situations where examined for consideration to developing standard.
• What is the appropriate use and display of these various mechanisms? What improves usability and what degrades it? In commenting on Ben Hammersley's TrackBack threading experiment I wrote it seems the time is near, even here, where we need to begin discussing when is it appropriate/useful to use these different mechanisms and how are they best presented. Another case in point, since implementing a number of these mechanisms, Sam Ruby's comments board have been filling up with various links and excerpts to the point its becoming hard to grok.
• Integration of RSS and a consolidation of efforts. Post-It uses a superset of the TrackBack. Is ComeBack was based on TrackBack's infrastructure and has a very similar interface, but breaks comparability. Post-It is quite similar to RESTLog. All make use of RSS or RSS-like structures including Sam Ruby's automatic linkbacks and let's not forget MLTFO (More Like This From Others) effort that happened over the holiday season. One thing is becoming clear RSS is bloody important and highly useful and far more then just a way to read news outside of the browser so we can stick it to the BigCos.

The subtle and underlying theme I draw from all of this is that RESTful interfaces that inherent in the Web's design work and have yet to be fully explored.

Here is to experimentation, innovation and evolution.

I was pleased to wake up this morning and learn I have become an uncle for the first time. My brother and his wife are now the proud parents of a healthy baby boy -- the first Appnel boy of this generation. Just what the world needs!

lazy \La"zy\

1. Disinclined to action or exertion; averse to labor; idle; shirking work. --Bacon.
2. Inactive; slothful; slow; sluggish; as, a lazy stream. The night owl's lazy flight. --Shak.
3. Wicked; vicious. [Obs. or Prov. Eng.] --B. Jonson.

Source: Webster's Revised Unabridged Dictionary

I'm all for the concept of the LazyWeb and I'm quite excited by its potential. Shelley Powers put it best when she wrote I think we're seeing a new form of open source development, based on technology developed for the community and its immediate, expressed needs. A case of community searching for technology rather than technology on the hunt for a users.

Lazy doesn't seem to be the word for it because members of the community describing its needs are taking action requiring some work to clearly articulate their need.

In his article covering the LazyWeb and its significance, Clay Shirky explains that term first coined by Matt Blackbelt Jones initially meant If you wait long enough, someone will write/build/design what you are thinking about. The concept has since evolved to mean I describe a feature I think should exist in hopes that someone else will code it. The concept has evolved, but the name has not to reflect that change.

I'm actually not sure what the right term is, so I suppose in essence this is my description of a need -- the need for a more appropriate term. The term seems like a slight that doesn't exactly encourage participation for those who are unfamiliar with the concept. (A form of Developers Have Blind Spots?)

I'm the type of person who reads a request and develops something. Community software development needs more input from users and needs to encourage their participation anyway we can -- like not describing them as slothful or the like.

Mark Pilgrim is peeved after examining the XHTML 2.0 specification. He writes:

I bought into every argument the W3C made that keeping up with standards, validating, and using semantic markup now would somehow “future-proof” my site and provide some mystical “forward compatibility”. How about some fucking payoff now? How about some fucking compatibility?

Standards are bullshit. XHTML is a crock. The W3C is irrelevant.

I don't know if I'd quite phrase it as Mark, but I think he has a right to take umbrage. I'm scratching my head on some of these and asking why? I think the first expert that explains these changes with the Semantic Web should be shot. (In effigy of course.) It's times like this I feel like the W3C is my mother making me eat my vegtables.

Scott Andrew comments No one is going to deploy this beast. The architecture astronauts have done their work, abstracting it to the point of absurdity. So what? He continues For 2.0 to survive, it has to be rethought, renamed, or retired. But please. Standards aren't bullshit.

Joe Gregorio is right when he says ...he shouldn't complain too loudly lest he get drafted as a technical expert by the committee.

I'll vote for Mark. W3C specifications are rather dry -- they could use some sarcasm and four letter words.

Inspired by recent discussion and experimentation with TrackBack around the net, I've developed a Perl module encapsulating its core functionality.

XML::TrackBack is a fairly rapid "OO modularization" of the TrackBack functionality (with hasty documentation) found in the reference implementation and specification. It removes the display and management features found in the reference implementation in addition to its reliance on CGI.pm. I take no credit for the genius of TrackBack. My motivation in developing this module is to make experimentation and implementation of TrackBack functions a bit easier. This module can be found here.

[UPDATE: This module has been released into CPAN. Its location in the module heirarchy has been changed to Net::TrackBack.]

The module requires LWP libraries.

I've done a fair amount of testing of this module myself, but for now this module should be considered ALPHA software. In otherwords, the interface may change based on the feedback and usage patterns that emerge once this module circulates for a bit. Once I feel pretty certain that its stable I'll release it to CPAN.

Your feedback and suggestions are greatly appreciated. There is still a lot of work to be done. This module is far from completed. Here are some brief thoughts:

• discover should probably return an array of hashes.
• receive_ping does not handle namespaces properly. You're OK if you stick with the standard prefixes.
• Does not support extended Dublin core elements such as <dc:subject> and so on.
• Implement TrackBack threading feature?
• Implement TrackBack challenge response feature to thwart spammers?

Gouge away.

[UPDATE: While I was writing this post, Sam Ruby posted likeminded comments and proposes a challenge: In the spirit of the BDG to SOAP 1.1 which exposed all of the machinery of SOAP, I'd like to request that proponents of either the Blogger API or the MetaWeblog API produce a similar BDG for their protocols, and would like to request that it include the first item from the Radio Weblog Post Module example.  I'll start by providing a sample for RESTLogPost.]

Jeremy Allaire is points to an RFC to extend the MetaWeblog API to handle binary media.

I appreciate his passion and advocacy of rich media forms in weblogging. I thought the multimedia weblogging experiment at the Macromedia DevCon was quite interesting and his frank assessment commendable. They certainly have value and are beneficial to evolution and understanding of the medium.

This said, I thought the RFC that he highlights is generally misguided and misses the mark. The challenges that he lists for multimedia handling, while true, are more a product of the Web's inherent design and the limitations of RPC-style APIs -- particularly XML-RPC which is not an extensible protocol.

I admit to having RESTful leanings, but I attempt to practice extreme anti-extremism so hear me out.

In closing his remarks, Jeremy writes the solution [for handling multimedia] we've come up with is very simple --- don't use the weblog to store or deliver any of the binary data, just use it to encapsulate HTML fragments that do live in pages and therefore can apply category meta-data and participate in RSS feeds. But this just doesn't feel right, it's sort of hacking around a system that hasn't yet been designed to handle multimedia conversations.

I generally agree and I understand where he's coming from when he refers to this as sort of hacking because in essence it is by design. The World Wide Web was designed as a system of loosely-coupled hyperlinked resources. Its success is due in part to the simplicity and low barrier to entry that text allows and binary formats cannot achieve. Changing its design would be taking the web out of weblogs.

Where I disagree is the connotation that the system doesn't feel right because is hasn't yet been designed to handle multimedia conversations -- particularly in light of the bigger picture.

This is not to say rich media does not have its place on the Web. It does. Tthe discussions and experimentations taking place intrigue me. They certainly have value and are beneficial to evolution and understanding of the medium.

Utilizing URLs and metadata formats such as RSS may not be ideal in this particular realm, but its the best and most scalable solution thus far and its what we have to work with now.

I said the RFC is misguided because it generally attempts to reinvent the wheel that the Web already created with more effort. People much smarter then I have discussed the merits and limitations. I found the arguments against more persuasive, so I'm no longer a supporter of XML-RPC.

Is the overhead of serializing the request and deserializing the response necessary when a POST /image-lib-service/some/path/or/post/id will suffice? This POST should return a 201 Created HTTP response code with perhaps the URI of that the image can be linked. This is something all Web browsers today can support without additional code or plugins. So I fail to see how XML-RPC is simpler or more effective particularly when it comes to handling binary formats like multimedia.

In the spirit of open and constructive conversation that drives evolution, I stand ready to be convinced otherwise.

[Mea culpa. I just realized I forgot to link to Sam's comments on Dave Winer's essay. Sam comes at it from a different direction and adds some noteworthy perspective.

Dave and I see some of the same data, but we interpret it differently. Here's my take.

Where interfaces are of the simple client/server kind, and where all the state is on the server, the trend I see for the future is that new interfaces will increasingly be defined as a simple HTTP GET.

This of course goes back to Sam's other post I added at the top.]

I just got around to reading Dave Winer's "First Essay of the Year." If you know Dave and can parse out his self-serving comments, he has some very good thoughts. For instance The Web uniquely wants to be used by everyone, not just for the purposes of big companies and their profits and paranoia. This is a foundation that I think we agree on.

Agreed. I wouldn't just differentiate on big companies though.

I thought Jeremy Allaire's commentary on the essay more relavent and better stated. Allaire writes The question it really provoked for me, and one that has been lurking in my mind for the past few months, is whether weblogging as we know it will truly become a mainstream form of personal communications and sharing, rather than it's current perceived niche as form of personal or independent Internet journalism.

Jeremy lists his personal perspective as to why weblogging is revolutionary -- publishing to the web is simple and your content is well structured and shareable. In order to gain mainstream acceptance he asserts weblogging, as it is known today, will need to Break out of the calendar journal or narrative metaphor and Embrace richer forms of expression through graphics, audio and video.

It would appear that 2003 is shaping will be the year of the two-way web and, as I like to think about it, the universal canvas.

In the continuing the review and discussion of Safari, Jason Kottke asks the intriguing question why are Safari and Sherlock two different applications? Jason argues that there is little distinction between web browsing and using specialized interfaces for structured data. He provides screen mockups of Safari to illustrate his point. An active discussion in the comment boards follows.

Back in September I wrote as the Internet continues to evolve into an 'Internet operating system'--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.

Reading about Remote Application Development with Mozilla, the mod_pubsub open source project KnowNow kicked off and discussions like the one Jason is leading have me reconsidering my view. Does the browser really need a mate in as much as it needs to expand its range?

Could browsers like Mozilla and Safari/Konqueror be the basis of simple lightweight structured interfaces for accessing network resources and microcontent? What if these browser brought bookmarklets and remote XUL to the forefront as equal partners to viewing webpages?

More intriguing questions and experiments lie ahead.

From an article published on CNET today:

An international standards body announced Wednesday that it has taken on the task of improving on the omnipresent URL, or Web address, to give developers a cleaner way to design and locate Web services.

The international standards body is OASIS. The proposed effort is called Extensible Resource Identifier (XRI) a method for identifying any resource--from a Web service to a particular file--across different network domains, applications and transport protocols.

The article continues:

You can think of XRI as a system that provides 'URLs for everything'--data, systems, organizations, services and people. Currently, we don't have a single, application and protocol-neutral way for identifying these types of resources, said Jason Bloomberg, an analyst at ZapThink.

XRI will build off the URL systems of today and work with the Universal Description, Discovery, and Integration (UDDI), a Web services standard that provides a listing for locating Web services on a network, according to the OASIS committee. It is designed to go further than the leading network directory standard, LDAP (Lightweight Directory Access Protocol), in unifying different types of network directories, Bloomberg said.

I don't see what's new here other then including UDDI into the mix -- something that should have happened in the first place with existing URLs, DNS and Web infrastructure.

[UPDATE: I still stand behind my assertion on WSIL when I wrote It's what the Web services space needs now. I would go so far as to argue that WSIL should have preceded UDDI as the solution we all need for services discovery, and is a logical stepping stone towards extensive Web services repository services for those who eventually require them. It disappoints me that WSIL has not received more attention or scrutiny.]

Someone please put UDDI out of its misery. The attempts to make UDDI useful and worthwhile keep getting more and more desperate. The RESTonians are going to have a field day with this. Its so crazy they may just completely ignore it.

Apple announced the public beta of their OS X browser Safari with much buzz and less then stellar reviews.

• CNET : Apple Computer's Safari browser offers little challenge to Microsoft's browser dominance, analysts said Tuesday, but the Mac maker could benefit enormously if it can wean itself from Internet Explorer.
• Mark Pilgrim I’ve downloaded and installed Safari. This review is mainly for web designers who now need to support yet another browser. It is in no way a judgement on Apple. All browsers have bugs, and all web designers need to know about them. Dave Hyatt, one of Safari's developers, responds here looking for test cases.
• Mena Trott: My initial response is this: Safari's bookmark and history management, the Google bar and spell checking are the three biggest gains for my own use. The inability to turn off anti-aliasing text really puts me off, however (like previous versions of Chimera, we may be able to fix this by editing the preferences file -- wherever that may be).
• Ben Hammersley: Sadly, at first glance it's shit almost-shit - No tabbed browsing.
• Anil Dash: Today [Apple] launched Safari, which is a Gecko (Mozilla engine) browser that loses Chimera's tabs and adds brushed metal ugliness. Maybe the tabs will show up when the browser's out of beta.
• Scott Andrew: It's too bad that Safari identifies itself as Mozilla/Gecko, when in fact its rendering engine is based on that of Konqueror. There's going to be a lot of confused user-agent sniffers out there. A lesson, I suppose, on the perils of trusting the USER_AGENT string, and other spoofable HTTP headers.
• Ben Hammersley (again): In what must be the fastest, most in-depth, distributed product review in history, Apple's new browser, Safari is being bashed about all over the blogosphere. Last night I was less than overwhelmed, but this morning I'm a little more happy.

Apple's use of the Konqueror/KHTML rendering engine as opposed to Mozilla Gecko is a bit controversial (or more accurately intriguing), but in the long run will be beneficial to the space. Instead of one open source engine, developers will have more choice and the inherent flexibility that two different efforts provide. There is some valid concern that another engine will divide the efforts of the community and introduce additional quirks and standards incompatibilities for designers concerned with universal access to work around. With Apple's support and dedication, I'm optimistic that those issues will be surmounted -- take David Hyatt and quick and open response to the community's feedback.

The 17 inch monitor PowerBook Jobs introduced is rather awkward looking. While its only an inch thick, the length and width in addition to all of the dead space around the keyboard reminds me of the old school laptops that that where the size of a suitcase.

I'm still resolved to follow through on my resolution. With reviews like InfoWorld's who wouldn't? I don't think the jumbo screen model is for me though.

[UPDATE: I've made a post to my O'Reilly weblog based on this one here. (The comments board is open.)

The holidays (and associated downtime) are over and its back to business. This is a summary of the interesting and noteworthy news and posts that where made while I was out.

MT: Simple and Powerful Text Formatting

To allow both more control and easier formatting, we're adding a new feature in the next version of Movable Type: Text Formatting. This will replace the current "Convert Line Breaks" option. Or, rather, the current "Convert Line Breaks" will simply be one of the available text formatting options, along with (hopefully) many other options, from POD to XML to Wiki. [SixLog]

I'm looking forward to this new feature. It couldn't have better timing. (OK I could be have come out over the holiday, but you get the idea.) I'm starting up on a project for a client who needs a content management system. I recommended MT and they took my recommendation. Now the issue I face is that the know nothing about web development or (X)HTML markup. What little web development they've done has been with FrontPage. In order to save them from learning and then struggling to publish their content and news with (X)HTML markup, I considered some alternate text formatting system. I've examined a couple different Wiki formats, Zope's Structured Text and Textile. While all are a step in the right direction, they are a bit more cumbersome and obtrusive for a non-technical user. I'm now nearing a first draft of a text formatting system that is based on the text formatting conventions commonly used in email. I hope this is simpler and easier to learn. Watch hear for more on that.

MTAmazon TrackBacks

The MTAmazon site is now running MT. It’s quite amazing to me that a free service like SourceForge would provide CVS space, download servers and bandwidth, AND Web hosting that supports MySQL and Movable Type. [Adam Kalsey]

This is an intriguing use of weblogging tool. Makes complete sense though I have seen very little of it happening. MTAmazon's use of TrackBack to create a list of MTAmazon will be interesting to watch as a similar discussion has begun on the mt-dev mailing list.

The LazyWeb

Ben Hammersley announced the creation of the LazyWeb using TrackBack links. "If you have something you'd like made, or invented, or written, write about it on your blog, and then trackback to the LazyWeb site (trackback url: http://blog.mediacooperative.com/mt-tb.cgi/1080 ). The rest of us can watch the site or feed and see if we can help out."

Shelley Powers comments "I think we're seeing a new form of open source development, based on technology developed for the community and its immediate, expressed needs. A case of community searching for technology rather than technology on the hunt for a users."

Trackback Threading

Sam Ruby notes on Greg Reinacker's call to action: "So, everyone, how about implementing TrackBack and/or Pingback on your weblogs - and let's see where it takes us?" Sam points out that the next logical step is trackback threading though issues may exist. I think we've only begun to scratch the surface of TrackBack's potential. Its an area of thought that I'm going to be giving considerable thought and attention to in the coming months.

Blosxom 0+6i BETA 1 released. 0+7i already on deck.

Aside from some basic cleanup, the big deal here is -- yes, it's true! -- STATIC RENDERING. [Rael Dornfest on the blosxom mailing list]

This is a much awaited feature. Much of the code (about 137 lines) is display text. In lurking on the mailing list it would seem the script are generally modified from its original form. Makes me think. In his announcement Rael also said "I've already started work on 0+7i's actions and pluggability (woohoo!) which I'll put into beta over the next couple-three weeks or so."

Software, Jim, but not as we know it

As we boldly explore the new universe of service-oriented architectures, we should not be surprised if software begins to assume unfamiliar, alien forms. [Phil Wainewright]

Agreed Phil. To quote a famous philsopher "you must unlearn what you have learned." We must forget what software is/was and seek out what it is becoming. Phil pointed out the recent example of Jon Udell's LibraryLookup as an example.

Udell's BYTE.com archive restored.

Early in December, Jon Udell reported that his former employer CMP had chosen to make the entire archive of BYTE.com a subscription only services. Just before Christmas Jon announced:

The 115 columns I wrote for BYTE.com are now restored to the public Web. I took this step reluctantly, and would have preferred that the original namespace remain intact, but so be it. Those columns that have continuing value can now weave themselves back into the fabric of the Web.

Great. I agree with Jon that those columns have value. I have a deep appreciation for many of his insights and the elegance in which he expresses them. Here are some of the articles that I’ve been going back to lately:

• The Universal Canvas
• The Universal Canvas Revisited
• The power of the URL-line
• The Event-Driven Internet
• Website API discovery

Microsoft ordered to distribute Java.

CNET (amongst many others) reports "A U.S. district court judge on Monday ordered Microsoft to include Sun Microsystems' version of Java with the Windows operating system, citing the software giant's history of undermining the platform-neutral programming language." Of course, Microsoft is appealing.

I have mixed feelings about this ruling. On one side I'm glad because I was highly disappointed with the DOJ's settlement with Microsoft after being declared a monopoly. Now that great injustice is in the books all that is left are civil suits. So I'm glad to see some momentum the other way. At the same time I am disappointed that Java is being forced onto users. If Java on the desktop was well done and useful I would expect a significant number of users would have opted to install it. Java on the desktop and in the browser is rather poor and demonstrate Sun doesn't get it -- or perhaps they are too stubborn and blinded by their own hatred of all things Microsoft.

I've got a new theory, based on the responses I've received to my Craig's List posting for a software/hardware engineer: It's no wonder we're seeing an increase in unemployment, people seem to have no idea how to apply for a job these days.[megnut]

Ouch. Meg has cause to be a bit frustrated and I'm sure was well meaning, but living in the NYC area this one hurt as I and many of my colleagues have been forced in freelancing. While Meg makes some good points about applying for work, I don't think she really appreciates how difficult it is to find full-time employment in this sector and this region.

Sheley Powers quickly responds and a rapid exchange ensues between she and Meg in the comments of that entry.

Meg reports she got 30 resumes which is remarkable low. It is my understanding that recruiters are getting upwards of 500 resumes for a single NYC-Metro position on the major job boards.

There are a lot of good people out of work in this area particularly in the Internet and the technology space. Many of my former colleagues are unemployed for a year or more. Some are getting by with freelancing, others have moved, some have gone back to school and others have completely given up and switched careers to something like teaching.

I have been enjoying my freedom since May, but know it isn't going to suffice in the long term being the (former) majority breadwinner for my family. So I have been submitting my resumes looking for something more stable and predictable. I do many of the things Meg suggests. (In case you're wondering I am not one of the 30 that submitted their resume to Meg's listing -- I felt I wasn't what she was looking for and chose not to waste her time or mine.)

Many of the listings I have been looking at generally have a highly specific list of required skills (5+ years of high volume transactional Java systems with existing knowledge of international derivatives trading...) with a DO NOT APPLY IF YOU DO NOT HAVE ALL OF THESE REQUIREMENTS. I usually seem to be missing one or two. Still I have found several dozen listings that I have submitted my resume to where I was highly (sometimes overly) qualified. I submit it with a carefully written, customized proof-read cover letters to not even get the courtesy of a "we received your resume" or "thanks, but no thanks" reply let along a single interview. Most listings on job boards do not list any type of human contact information -- name, phone, or email. Nothing. Nada. Zip. Many include DO NOT ATTEMPT TO CALL OR EMAIL US WE WILL CONTACT YOU. It starts to really take a heavy mental toll. Here is how I rate the source of my next job.

1. Personal industry contacts -- High probability)
2. Recruiters -- Some chance
3. Miracle -- Long shot, but hey you never know
4. Job Boards -- Seconded only to hell freezing over

I have come to the conclusion that job boards, in this market are worthless to job seekers. I've all but given up on them. I have been far more successful with personal contacts. They have obviously not landed me anything full-time, BUT I got a return call 100% and at least an interview of some type over 50% of the time. Most of my personal contacts are in companies that are in as bad a shape as my former employer (hanging on by a thread to remain solvent or being acquired) or have just frozen hiring until the economy pick up. So I'm bidding my time and managing my money careful with some help from the State of NY. In the meanwhile I'm writing and consulting -- even working on some unfinished business.

On a related note, new to New York Meg posts her first celebrity siting. Just wait till the spring and summer Meg you'll be sick of them -- and like a true New Yorker you really won't care. ;)

CNET has posted a video interview (the link pops open a window) with Paul Festa and Opera Software CEO Jon von Tetzchner demonstrating their mobile browser that I wrote about here. At the time I wrote:

I've always been skeptical when it comes to these attempts to repurpose web content on a mobile device as Opera's proposal or existing implementations such as Danger's HipTop browser. I've never seen them succeed at anything but frustrating users.

Web pages are designed for large high-resolution color displays, the use of keyboard and mouse and a reliable and relatively high bandwidth connection. Being a display language HTML is not terribly efficient or reliable for consumption by another application. "Qualified guessing" will yield the equivalent of a Frankenstein monster. It’s a hack at best.

Yes, if designed properly a Web page will scale gracefully and adapt to different displays and resolutions -- IF is the operative word though. Like eating your vegetables, most of know we should do it, but don't. Face it, web sites do some rather freaky things with HTML. You don't have to go past the world's most prominent software company's site to witness that.

I still remain skeptical this approach will ever work -- perhaps even more so after watching the video interview.

The interpreted CNET gateway used in demo seems readable, but it hardly looks like its original self. It also requires a lot of scrolling to read. The demo is also done using Sony Ericsson's P800 mobile phone which sports an extra large color screen. Goes to a Nokia phone momentarily and switches back to the Sony Ericsson device before giving a really good look.

Personally I remain optimistic and intruiged with the utilization of well-formed RSS and XSLT in addition to the development of novel applications (most likely using J2ME) for users on the move.

In the spirit of no-news-is-good-news, I've taken the beta label off of mt-xml-smart my latest MovableType plugin for providing XML encoding and decoding beyond the basic capabilites of MT's native functionality. The plugin can be found here.

See my previous entry on the plugin for more details to its capabilities. Other then the beta label being removed, nothing has changed.

[Update: Sam Ruby notes a discussion on XML encoding in RSS feeds between Steven Noels and Ugo Cei. Its reoccuring discussions like this one (and also posts like Reverend Jim's) that drove me to write this post and this article eventually leading to the development of mt-xml-smart. Encoding of (X)HTML in the RSS item.description element is an unfortunate misunderstanding from the identity crisis the RSS format suffers from. It causes a lot of heartache even for the best of us with good intentions. While I'm not foolish enough to believe this issue will be or can be fully rectified, I hope that my advocacy and other works make things a little bit better then before.]

For my second post I'll break my first new year resolutions.

[UPDATE: I've added a few anwsers to blanks in my memory and a correction. Most are courtesy of Emma Hamilton and her database of 503+ commercial spots. Mike Castelletti also wrote in to correct me that its was Daft Punk and not Groove Armada that does One More Time. I knew that. I really did.]

[UPDATE 2: I've hyperlinked all cited recordings for your Amazon shopping pleasure. If this post answered a nagging commercial question it would be really cool of you to buy through my links.]

Until reading Mena Trott's post on "Press and Discovery" that linked to an entry on her personal weblog, I never realized that there was such interest in music used by commercials.

My family (and some friends) think I listen to odd, obscure and otherwise "weird" music. I don't really agree with that characterization at all. That's why I get a chuckle when I hear music by generally obscure artists that I've been listening to makes it into a commercial. They are listening to it in commercials and don't even know it!

Since it would seem by the long running comments thread on Mena's site that there isn't enough of this info out there. I thought I'd share some of my knowledge. These are some that come to mind in no particular order for those who may have been trying to figure out "that track" for themselves.

Dockers "Dinner Party" - Les Baxter "Tropicando"

Guy walks into a high society dinner party with a couple of women staring seductively at him. Once dinner starts we see them start brushing their stocking feet on his leg making him feel uncomfortable until much to his surprise he learns one of the gents at the table is doing it too.

Dockers "The Basketball Star's Pants" - Thievery Corporation "Coming From The Top"

A crowd going nuts welcomes a basketball star (presumably) getting out of a limo. He stops to sign a basketball for some kids and then stops at some screaming women. His coach sees it and points him to the locker room. As he walks away the coach notices the women are screaming about his pants. (Of course.) The action cuts to our star trotting out with his team in uniform before cutting back to the locker room where coach is sneaking back into the locker room and trys on the players pants.

Incidentally these two tracks used by Dockers appear on the same compilation album DJ Kicks a continuous mix by the Thievery Corporation -- its an excellent album I'm still listening to years later. Since the 2 commercials where released around the same time for the same product, I have to assume the producers o