Wednesday, April 24, 2002

The practical benefits of literary forms. As blogspace evolves all around us, new forms of writing appear. I mean forms in a technical sense -- literary forms, or patterns of writing. One of the most interesting of these is David McCusker's. Recently he explained why and how he writes in stanzas, with five fixed-length lines per stanza. "This obviously isn't poetry," writes David. "So you might wonder, why do I do it?" His answers resonated very much with my own sense of writing as an art which, like software, is creative yet mechanical.  [Jon's Radio] 9:32:31 PM

Friday, April 19, 2002

Let's Make a Better OPML. While browsing Mark Paschal's diveintomark this morning - Mark and Joshua Allen are my references on outline rendering these days - I came across this - disappointed ? - comment: So as far as I can tell, OPML is XML that isn't really XML, has (but doesn't use) a DTD that isn't really a DTD, and can only be properly defined as "whatever Userland's tools happen to accept at the moment".[diveintomark] Well I think Mark's right, and from what I've learned these past 2 months,I suspect the reason for the current situation is something like this [s l a m] 10:41:18 PM     I had a nice response to a recent column on Zope from Jeffrey P Shell, a longtime Zopista and former Digital Creations guy who has decamped to the skiiing life in Utah. Jeffrey wrote one of the first BYTE columns on Python, longer ago than the web seems to remember. Anyway, in my column I talked about scripting Zope from the outside, using the RESTian approach of reverse-engineering its HTML management forms and calling them as URLs. I knew that XML-RPC was another way to do this. Jeffrey pointed out a third, little-known approach that taps into Zope's "lizard brain." Did you know that Zope has always had a simple RPC mechanism, predating XML-RPC, and even predating Zope itself? There was a little piece of Bobo, which is now ZPublisher, called 'bci' for 'Bobo Call Interface'. I'm almost ashamed that more wasn't done to promote BCI, or turn it into an actual RPC mechanism (it doesn't marshal return data), because XML-RPC, while simple, is just a little too simple (no concept of None/NIL? No concept of authentication except as part of the API?). And SOAP.. *sigh*. Anyways, ZPublisher.Client (which can be used without any other Zope modules, so you could install a copy of it into a common place) is another wy to do that Perl script that you wrote, while maintaining a cleaner syntax than writing a long URL. It basically generates the same URL (with all of the correct Zope marshalling, although I don't know if it knows of the more recent marshalling options) and does the same job. from ZPublisher.Client import Object myCatalog = Object (   http://host:port/repository/myCatalog) myCatalog.manage_catalogFoundItems(   obj_metatype=['Image', 'File'],   obj_permission="Access contents information",   search_sub=1, btn_submit="Find and Catalog" You can see the similarities to XML-RPC, which you might even be able to use in this situation, but there are some niceties about BCI. When constructing a ZPublisher.Client.Object or ZPublisher.Client.Function method, you can specify a username and password and you will be authenticated over Basic Auth. You can specify which HTTP method to use (GET/POST/PUT). You can upload files just by passing a Python file object (basically anything with a 'read()' method).  You can also catch remote exceptions. While I recognize that XML-RPC has the concept of 'fault', for more intimate Zope scripting, sometimes more knowledge of the cause of the fault is required. This is the only real marshalled data that ZPublisher.Client (BCI) sends back. Cool! By the way, Jeffrey is trying out a blog. I hope he sticks with it. He's a wonderfully thoughtful and articulate writer, and a really clever guy. l  bet he'll have OmiOutliner hooked in before long. Looking into blogspace with fresh eyes, Jeffrey wondered "Why write when there's so much else to do? Who's reading?" These are great questions. I of course get paid for my writing, though not for what I write here. But what about most folks? Why write? Who will read? Lots of people have lots of different reasons. For me, it's mainly about optimizing information flow and managing attention. In a recent column I explored the idea of storytelling as a tool for project coordination. That's closely related to what Dave Winer means by "narrating work" (and is demonstrating in his outline). We do this narration all the time in interpersonal email. Something interesting happens when we instead write messages addressed to spaces.  Defining why it's interesting is hard to do. But I'm closing in on it. Today I realized the following analogy may hold: loosely-coupled message-driven architecture, the mantra of the web services movement, is precisely what blogspace is becoming for the realm of human communication. When we adopt this style of communication, we give up some of the benefits of tight coupling: message acknowledgement, tight feedback loops. But we gain (maybe) the ability to scale beyond what is possible when tightly-coupled messaging (email, discussion groups) is the only available mode. This doesn't mean there's no benefit to tightly-coupled interpersonal messaging. It only suggests that the loosely-coupled mode is also important. 10:01:07 PM

Sunday, April 14, 2002

From: http://www.oreillynet.com/cs/weblog/view/wlg/1283 The Google Web API, while hopefully grabbing the attention of more traditional Web Services types, is really for who Tim O'Reilly affectionately refers to as "alpha geeks": The alpha geeks are often a few years ahead of their time. They see the potential in existing technology, and push the envelope to get a little (or a lot) more out of it than its original creators intended. They are comfortable with new tools, and good at combining them to get unexpected results." Google's arrival at the Open Services experimentation party finds them in good company. Userland's Radio Userland is a wellspring of DIY Web Services bootstrapping. Jabber-RPC transports XML-RPC messages over the Jabber instant messaging framework. Watson provides a stunning example of putting a GUI front-end on Web Services. My own Meerkat Open Wire Services provides open URL-line and XML-RPC interfaces which have reaped some unintended yet wonderful uses. 1:50:10 PM     Google APIs, New York Times news, new tools, lot's of stuff is happening in the world of web services and especially in RadioLand. I've started to think about all this as "Reusable Info". What is really happening in these days is that new ways to store, distribute and manage information are seeing the light on almost daily bases. All this will have a huge impact on how we work, live and communicate, but it's not yet very clear how. At evectors we are experimenting every day all these new communication channels, and we try to put some sense in all this from a work environment POV. Basically what is happening is that every piece of information, every idea, every concept, every document is getting its own url. You can access it and reuse it. All borders between you desktop and the rest of the universe are fading, you can borrow the search capabilities of Google's powerful servers from within your favourite application, or you can read news from the New York Times on the same page containing the news from your co-worker telling you what's up today. Hmmm, it's going to be interesting... very interesting. ";->" [Paolo Valdemarin: Paolo's Weblog] 10:28:39 AM

Saturday, April 13, 2002

Russ Documents Radio Why shouldn't we use our (Google) Boxes for the sheer whimsy of it? I feel a tutorial coming on .... if I can do this in ten minutes, so can you. [Russ Lipton Documents Radio] This is where I'm missing the big picture. While the steps I took to create a Google Box were easy and straight forward - I followed Dave's instructions to the letter - I'm not sure how to apply it for every day use. Do I go back through the steps in the instructions and redo them for a new topic every time I want to change? I hope Russ answers some of these kinds of questions! Oh, yeah...anybody know how to make the Google Box narrower or with smaller type? Dave has done it at The Scripting News site. How do I change the attributes of the box? [Steve Pilgrim's Radio Weblog] Oh my I think I'm beginning to understand the relevance of the "Google API". If someone can list the top ten searches for "The New York Mets" it follows that with the right query you could get the API to list "The last 10 New York Met scores". In that way the box would become the XML-RPC feeds that other people are working on. The guy who wrote the script to call the last 10 races at the New Zealand race track could also do it via a Google search. And since it can search the web or your desktop/intranet in this way you once you learn the proper search terms you can pull any information you want into this box. Is this what Dave calls a "bing"? 8:22:12 PM     Web Services John does an excellent job of building the business case for web services. For years, I've been involved in complex application integration projects involving the disparate distribution systems of dealers and distributors. "Importing" an invoice into the dealer's software from the distributor's software when a purchase order was filled and shipped to the dealer was complex and cumbersome. If I understand what is really happening when an application called Radio "talks" to an application called Google, then I have to agree with John that Userland is truly on the cutting edge of what the internet can become. This is great stuff: Desktop webservices and composite applications.  One of the most exciting aspects of desktop webservices is that I can build pages on my desktop that automatically aggregate data from across the web and from webservice enabled corporate applications.  This is effectively a personal portal that could include search (Google) of the Web/LAN/desktop, financial info from a place like Yahoo finance, corporate sales data, corporate financial data, corporate inventory data, news (RSS),  and even data from peer web services (data entered or auto-aggregated by co-workers in a structured format -- contact lists, bookmarks, calendar entries, spreadsheets, etc.). Better yet, I have complete control over the presentation of that data.  With a little programming effort, I can incorporate business rules (with tools that can be automated for me) that do things for me based on that data.   I could also attach a post button to all the data I collect so its easy for me to share it with co-workers via my weblog.  It puts me in control.  This is the ultimate composite application.  A borg that consumes all others.  I don't want to learn or interact with hundreds of different websites or application specific clients.  I want it all on my desktop, running in my browser, where I can modify, manipulate, and publish it. [John Robb's Radio Weblog] When you put it this way, I can understand it! [Steve Pilgrim's Radio Weblog] 7:24:56 PM     Dave has a link to Matt Webb's Web Log. In it he states: Yes, we are entering the next phase of the web. Tim O'Reilly, Tim Berners-Lee, and even Matt Jones can say this with more clarity than me, so I'll leave most of it to them. But here's where I think it's going to come from: Web services [SOAP, xmlrpc] are symptomatic of a understanding-shift. We know the net well enough now to give it APIs, languages [XML, IM bots], which makes it scriptable. And I think the reasons we're able to make it scriptable is because we understand it. The www itself, now it's a combination of two things: The real life thing and the technology combine to make a virtual thing. And it used to stop there. But because we understand and because the capability for scripting is there, that means we can recombine things on the net that we couldn't touch before. And recombine them, and them, endlessly recombine. Web services [and what they represent] truly are an order of magnitude change. Oh, but so what. Progress happens. Blah blah grand sweep. I want to subscribe to this guy's RSS feed yet he doesn't have one. Why not?   7:09:00 PM

Sunday, April 07, 2002

Dave has a pointer to a Financial Times story that mentions Andrew Sullivan's web log and the fact that it has just turned a profit. I notice that he accepts donations and has received a minimum of $11,000. He mentions the site is expensive to maintain. This is obviously a concern as I look at the cost of maintaining these platforms. Interestingly my categories include "Investing" and "The Virtual Corporation". Deep down I feel there is enough brain power among web loggers to bring substantial financial benefits to this undertaking. In fact the Financial Times piece states:  "While most bloggers comment on news reported elsewhere, some do their own reporting. Making use of the latest wireless internet access technology, they can tell the world as fast as they can type what a corporate executive or politician has said. Even wire service reporters cannot beat them because the former must file copy to a news desk before it is published."  This reminds me of a quote by Carnegie or Mellon or one of the old Moguls saying that he made money by having information before everyone else did. I have long thought that web logs would be better platforms to discuss individual stocks than the Yahoo message boards. With the ability to subscribe to the RSS feed of a individual stock web logger attending the investor conferences you could be notified before the main stream press of interesting developments. Just a thought. 7:58:16 PM     I was struck by the fact that Jon Udell has posted a script that displays the sites he has subscribed to on his main page. As this develops classifications people with like minded weblogs will be able to network through this service.  8:35:18 AM

Saturday, April 06, 2002

When I look at everything the internet can and could do I think of one thing: Radio Userland. However, there are many things that need to be ironed out. The first one being the fact that I think I could probably sell a bunch of Radio Userland licences but there's no commission structure. For such a viral product I find this bothersome. 6:16:48 PM

© Copyright 2002 Ian Bruk. Last update: 4/14/2002; 6:16:04 PM.