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.
Former URL: http://weblog.infoworld.com/udell/2002/04/18.html#a197