May 2003 Archives

In another thread to my O'Reilly post on Weblogs, Web services and the future, an anonymous poster raises the notion of using SOAP instead of XML-RPC stating SOAP is a great service, supported by all the big players. Quite a valid thought. Another anonymous poster chimes in SOAP is a useless waste of time and a wonderful example of NeedlessComplexity. Use HTTP. What else needs to be done besides GETting data, POSTing new data, PUTing changed data and DELETEing dead data? Focus on clean resource-space identifiers [URIs] and meaningful XML blocks. Then, DO NOT wrap them in an XML-RPC or SOAP noise. Just use the data.

I understand where this anonymous poster is coming from. As I have said repeatedly RSS is the Web service we already have. I also admit to having RESTful leanings however they are not absolute.

I asserted that creating a SOAP/RSS hybrid would simpler then most people think when document literal encoding is applied. Most developers are familar with the RPC encoding which does have more overhead and issues particularly in this case. Encoding document-based content into RPC forms is part of the reason why the XML-RPC based solutions struggle. Sam demonstrates the notion of SOAP interface with RSS at the end of his essay. Here is some additional reading on the matter here here and here. In comparision SOAP/RSS is not that much more complex then just RSS over HTTP (the pure REST way).

SOAP does have its place. For example, wouldn't it be helpful to post to your weblog via an email message in a standard way? (This assumes the client is handling the SOAP encoding of course.) I think, yes.

A noteworthy thread with Dave Winer in response to my O'Reilly weblog post on XML-RPC as the basis of Weblog APIs. Dave starts by writing:

To Timothy, dive in a little deeper into the MetaWeblog API. It is based on RSS 2.0. It's exactly what you want. Or put it another way, what more do you want?

As I state in my post: international character support, robust extensibility and cohesion with RSS. The MetaWeblog API was released about 5 months before RSS 2.0, but I look past that factual error and reply:

I would begin with the first point in my post – international character support. How would you provide it in a frozen specification that explicitly states strings to be ASCII?

Dave replies:
Read the archive of the XML-RPC mail list. This issue comes up regularly. I get tired of doing repeat performances. XML-RPC is so deployed it just can't be changed, not by anyone. If you do a little digging you'll see how other smart people have dealt with this issue. I've given my opinion more than once.

I'm aware of these workarounds. As I've noted there are a number of different solutions including breaking from the specification to support UTF8. I would be curious to hear what users working with languages that don't fit into ASCII think.

There are different degrees of smart. Smart workarounds. Yes. Smart implementation of international character support. No.

When Dave says, XML-RPC is so deployed it just can't be changed, not by anyone which gets to the heart of my point. If XML-RPC cannot be evolved then indeed it is not the right thing for a publishing API to go forward with.

Update: Dave is turning up the volume and stumping through his Harvard weblog which Shelley Powers comments on.

Just as I thought it was OK to speak, bad news for O'Reilly's Blogging Hacks book I was contributing to.

Ben Hammersley recently told the contributors that production of the book would cease immediately. In a note to all contributing Ben states, "the long and
short of it is that the channel, the bookstores and so on, are saying that
weblogging books are just not selling."

Undaunted Ben has announced and begun work on The Book of Blog with input from the contributors and others.

While disappointed in the ultimate decision, as a business person I can understand O'Reilly's reasoning. Blogging books have not sold well and distributors are not interested in another for now – no matter how much better it was suppose to be. No matter how well intentioned O'Reilly's advocacy is they are still a business that sells primarily through distributors. No sales. No profits. No sense in going forward.

I disagree with the notion that blogging books cannot sell. Absent from the market is a blogging book that goes deep into the technical/how-to that I sense many are seeking. I know because I can see the stats of my MT plugins article and I get a lot of how do I email from my work in the MT community.

The Blogging Hacks I think would have succeeded in taking a deeper dive into blogging. However I was concerned that covering such a wide breadth of tools in one book as Blogging Hacks endeavored would have succeeded. The vast majority of users work with just one tool for weblogging. If the book where to cover 4 tools in equal amounts then only 25% of a book would be useful to a reader. This would make the books cover price rather steep for all tool audiences and that I suspect few would have would have bothered purchasing the book.

The little grey cells are abuzz as I seriously contemplate an effort to put my money where my mouth is. Stay tuned.

While buried in my work the past few week, I missed noting two happenings I'm happy to have assisted in. The release of mt-allconsuming and Sun retitling an inflammatory JavaOne session.

Dave Seidel announced the release of mt-allconsuming a MovableType plugin for integrating info from the All Consuming service. I let Dave use some of the code from my mt-rssfeed plugin. Dave also mentions that my Developing MT Plugins article showed him how to get it done. Glad I could help. Good work Dave.

A few weeks ago I noted a post by Andrew Oliver via Sam Ruby in my O'Reilly weblog. Andrew pointed out an inappropriate and inflammatory titled of a JavaOne session where an independent view (Sun staff was on the panel) of why the JCP is better then open source. Last week Andrew noted that we can make a difference. The chain-reaction of our posts succeeded in getting Sun's attention who have retitled the session to something more appropriate and less inflammatory. Andrew writes I hope this demonstration proves that we can make a difference. I have a lot more hope that with each of us watching and speaking out, that Sun will over time behave well without our help. Its up to us to be watchdogs. The onion smells much better today. I agree. Good work Andrew.

Paul Graham: Hackers and Painters

Tim O'Reilly: Why Scripting Languages Matter
Paul Graham puts his finger on why languages like Perl, Python, and PHP have an enduring place in the computing firmament. And a lot more, as he explains why hacking is a lot more like art than it is like science or engineering.

Tim O'Reilly: The Crafty Turk
Great response from Dave Stutz about my blog on "the importance of scripting." 

Simon St. Laurent: Why Markup Languages Matter
Tim O'Reilly emphasizes Paul Graham's observations on a sketching mode for programming. One of my favorite aspects of XML - and markup, more generally - is that it allows a similar improvisation process for data structures.

Sam Ruby on Why Markup Languages Matter (with comments)
If anything, I feel that SSL understates the need for evolution and flexibility in data structures.

In recent weeks a significant amount of discussion has been ongoing as to the future of Weblog APIs. At issue is that there are two similar, but different Web service APIs in use – the Blogger and MetaWeblog APIs. Within each of those APIs are various interoperability and implementation issues and even some extensions. The community clearly wants one tool-agnostic API that all can utilize and integrate tools with, but there is differing views as to how this will and should happen. Full post on my O'Reilly Weblog.

Some interesting Wi-Fi news from the Big Apple.

Today during my commute into the city I passed Verizon setting up an extravaganza in Madison Park (23rd-27th street between Broadway and Madison). Seems Verizon is talking up the hundreds of hotspots they have deployed around the city. Oh yes… and that they and MSN have jointly launched a broadband service also. (That is the sound of one hand clapping that you hear.)

The hotspots are available to its DSL subscribers free of charge. Very smart of them. (Look here for more info.) They were handing out duel hotspot and subway maps in MetroCard holders. According to my pocket map Verizon's coverage in New York includes Columbia University/Morning Side Heights, Upper West and East Side, Midtown from 59th through Chelsea (coast to coast), The Union Square extended, NYU/Washington Square Park, Wall Street/Battery Park and Brooklyn Heights. (Why is their online hotspot maps are SSL protected? Maybe they are not as smart as I gave them credit for.)

Like I said, interesting. It doesn't help me really. Verizon provides such poor service to my neighborhood that I went with @Home now Comcast. I suppose it will be helpful in getting the market to innovate and keep moving forward at an aggressive clip. T-Mobile recently announced they are packaging mobile phone and Wi-Fi. (I'm really considering T-Mobile for my next phone to take advantage of that and justify my Starbucks coffee addiction.)

UPDATE: Seems I'm not the only one thinking Verizon's move could mean something to the price and service of broadband hotspots. Internet News is reporting that Verizon could spark me-too Wi-Fi efforts. This being said, Reuters notes in that whether it be broadband Internet access, 3G mobile phones or flat screen monitors, the high-tech industry has turned hyping new technologies into high art. Cashing in is another matter entirely.

A very productive discussion of an RSS profile has continued throughout the weekend and into this morning. Enthusiastically many have dived in – myself included. I still maintain that an important consideration has not been discussed and needs to. What are our design goals with this profile? (More specifically questions like the one I raised in my previous post, at what point does the specification stop and extensible modules begin?) This is a bit of concern to me. I don't think there is clear picture even if a certainly level of consensus is apparent in specific decisions. I'm am not so stuck on a specific set of constraints as much as I am purposeful and consistent decision making.

I think some discussion and clarity on this would be productive in further this discussion and its results.

Ben Trott has posted his thoughts on the issue of context in which an RSS profile should be developed laying out some of the type of information that needs to be considered.

The following is something in between that I putting out there as a conversation starter. Its loosely based on the design goals I set in the XSS profile I proposed last fall. I think they also coincide with what has been discussed thus far. Comments are welcome. Please use Sam's weblog here.

[UPDATE: Sam has opened a new thread on my post. I have modified the link above accordingly.]
Balance ease of use and authoring with ease of consumption by applications while maintaining the richness necessary to extended and adapt to various weblogging tools[1] and beyond. (In short, simplify and clarify what we have and how to extend and evolve it.)
Promotes best practices of emitting well-formed and useful RSS feeds.
Design around a simple common core of elements (title, link, description, channel, item) that may be extended with namespaces and modules.
The profile opts for namespaced elements in modules over tags in the default namespace. (i.e dc:date over pubDate. dc:subject over category etc.)
Design to maximize backward compatibility with the RSS 0.91 format and its descendents though some discontinuities maybe be unavoidable in achieving long-term benefit. This allows the profile to leverage the existing install base of 0.91 feeds and prior bodies of work such as Dublin Core meta data and RSS 1.0 modules.

[1] I understand what Ben is getting at when he writes as soon as we start discussing a core profile for RSS, we need to define the context in which that profile applies. I'm not sure if Weblogging is the correct term to apply to the context at hand. It seems that this profile would be quite applicable to other domains like traditional online news sites and publications such as CNet, the BCC and so on. Just a thought.

As the discussion of a unified RSS profile has continued on Sam's weblog, Microsoft's Don Box has offered an initial proposal of a RSS profile for comment. (Don has only addressed items so far.) Separately, Ben Trott has posted some of his own thoughts on what the format should be.

I really think before this goes further an important issue needs to be addressed. At what point does the specification stop and extensible modules begin?

For instance, looking at Don's item proposal, you have pubDate, comments, category, and author elements. The dublin core (dc) module has elements for date, category (subject), and author. The dc module also has a lot of other elements not included in this initial proposal. As I read Don's proposal, either a new module for meta data must be developed like dublin core sans the overlapping elements (which is silly) or design overlapping and redundant elements (which is silly AND confusing). Some tags need to be depreciated in order for RSS to move forward and achieve its greater goals.

I still maintain the best approach overall is going to a simple basic core with modules (many of which has already been developed) to easily extend the format based on the context in which it is being used. It would raise RSS feed quality and make them more neighborly for users.

Getting more specific on Don's proposal…

I'm liking the use of xhtml:body more and more. I wasn't sure what I thought of it initially, but it's growing on me. I applaud the call for the description to be for excerpts only and not contain markup.

Instead of title and description being an either/or where you use the description if the title is missing and use the title of the description is missing – revert back to the rules set in the 0.91 spec. Don Box has proposed a profile… derived from a description is not nearly as helpful to me in a summary view then a proper title like An RSS 2.0 Profile. If you are the type of person who writes many small entries and doesn't want to title them you could use something like tima thinking outloud. May 11 2003 20:12 -5:00. (Blog name and timestamp.)

-I don't agree with the proposed definition of the guid or link elements. The vast majority of feeds use the link tag to point to site feed originates from. What value is gained from this change? No one who seems to understand the concept of a URI has ever been able to explain to me why we need a guid element to replace the link tag. What function does the link tag as used today not provide?-

UPDATE: Just as I posted this I see that Don has posted a version 0.3 in the meanwhile where the delta states Embraced <link> as the one true URL container :-)

Looking forward to the continuing discussion.

Via Sam Ruby Dave Winer is calling for a profile to RSS 2.0 that blogging tools could strictly comply with in order to achieve interoperability. I would have preferred that we just had a specification that resolves the issues, but I'd favor a RSS 2 profile. I proposed one when more of forking and flaming was going on last fall. The profile I proposed is not perfect, but it maintains a high level of backward compatibility with RSS 0.91 which is still the most widely used format in use. Whatever the case, this should be an interesting comments thread to follow.

Wind'em up and watch'em go.

Ben Hammersley notes that his second book Blogging Hacks is now on Amazon for pre-ordering. I'm pretty excited because I've made a few contribution and owe Ben a few more. Perhaps my wife will believe me now so I can finish my parts.

Ben Hammersley notes a passage from Tim O'Reilly's email message to sent to ETech attendees:

My own favorite moment was hearing Mena Trott of Moveable Type try to talk Jeff Bezos into using trackbacks for Amazon book reviews, so that people could write reviews on their own blogs. Jeff seemed completely on board with the idea--I'm going to follow up with Mena and the Amazon tech staff to see if we can make it happen.

I hadn't gotten around to reading the email message – so I'm happy to see Ben calling attention to it. (Too bad it isn't posted online.) Thanks for helping me with my mail Ben.

During the conference I got some one on one time with Amazon's Colin Bryar (Director of Web Services & Associates programs) and Jeff Barr (Web Services evangelist) and pitched the idea of supporting TrackBack on Amazon.

I did get a couple shots of Mena explaining TrackBack to Bezos at ETech:

Picture 1
Picture 2

(Sorry for blurs and halo effect. The lighting was kind of poor and I avoided using a flash because I was so close.)

Ben's suggestion to introduce RSS to Amazon reviews would be also be useful extension. RSS and TrackBack already share a close relationship, but more can be done them even closer together with a few improvements, of course.

From an the InfoWorld article Microsoft seeks compelling PCs:

Looking to inspire PC buyers to upgrade, Microsoft is hailing life immersion technology, featuring multimedia and other improvements that the company hopes will compel users to buy new boxes.

Yes its called an Apple PowerBook or any other machine running OS X. I'm really quite pleased that I made the switch last month.

The article continues with more head slappers that sounds like iLife-envy.

What is it about Duran Duran that is so fun over 20 years later? Perhaps I'm being a bit sentimental about my youth. Not really sure, but I'm not going to think about it too hard and just enjoy it for now.