Jeffrey P Shell: Objects and the Web

Moving Toulouse

Sat, 11 Jan 2003 19:24:27 GMT

Industrie Toulouse has moved to A new home (toulouse.amber.org) and a new publishing system. Most of the archives will be there soon. The Radio site will remain up indefintely, but no new content will appear here.

Zope 3 reStructuredText Document 0.1

Sat, 04 Jan 2003 18:53:11 GMT

With Zope 3X alpha 1 out, I decided it was time to jump in again and see how it would be to write a new content object for it with associated components (adapters, views). I've tried to include comments in the files and README to document what I was doing as I was going along.

It can be downloaded here, and requires a fairly recent docutils and of course Zope 3X Alpha 1.

The current release is intended to focus more on documenting how to write a new content component for Zope 3 than on being a smart reStructuredText client. That functionality may come later.

I have some other thoughts about the process posted on ZopeZen.

FDoc

Sun, 27 Oct 2002 21:47:53 GMT

I've been asked recently about this FDoc project I keep mentioning. Today, I wrote a new document about it.

Regarding FDoc -- this is the new document, and goes over some of the design ideas as and after they've been put into use.
Compound Zope Documents -- this is an older document, written a few months ago during some of the initial coding of the base framework and a default end-user implementation.

On .Mac, part 1.3 - availability wrap up

Tue, 08 Oct 2002 08:53:01 GMT

Without going into too much details, tonight after mad birthday celebrations (where I spent too much time being tired drunk instead of too-much-dancing drunk), I came home to an email from Apple concerning the .Mac outages. Their claim, which I believe, is that there have been equipment problems. They claim the vendor has not been able to promise no more problems in the future, and work is underway to install new equipment. Hopefully this works out well for them and for us subscribers, and it's nice to be notified. In the past, when the service was free, I didn't mind outages and interruptions, but as web services get integrated more and more into desktop applications and environments, service availability is going to be a critical issue. Hopefully having paying subscribers will offset the high cost of service availability. Large scale web services like .Mac, whatever Microsoft .NET My Services morphs into, and other large offerings require more than just a single web server sitting in California. Backup, caching, and location issues abound for service providers. Even Userland's "Radio" servers have had problems in the past (but have run smoothly now for months). Other services, like LiveJournal have also had availability issues, and in fact LiveJournal is closed to free accounts that don't come in off of a referral. There are some other weblogs about Web Service Strategies that have better details than I can offer about the aspects of web services beyond SOAP, REST, or however the basic protocal is spelled for you.

A Zope 3 story - augmenting other components

Mon, 02 Sep 2002 08:47:43 GMT

It's very late, so I'll try to make this quick and write up more later. Today, I finally had enough free time in my coffers to download "Python" from CVS (aka - 2.3 pre-alpha) onto my old iMac, and augment that with "Zope 3" - the ComponentArchitecture project. Then I installed the simple but usable Job Board Example. I soon noticed that said JobBoardExample was missing out on a couple of things - an editing interface, and an XML-RPC interface. One of the notions of Zope 3 is that it's supposed to be easier for developers to embrace and extend other components by being able to write new "views" for them. So, I decided to write a JobEditView. I made a new Product (esentially, a plain Python package) called JobBoardEditor, and filled it with a couple of files - EditJobView.py, edit.pt (the page template to edit a single job with), and configure.zcml, the configuration file that ties it into the Zope system. It wasn't long until I could go to a Job object and traverse to my new edit form, and then have the submit go to my 'edit' method. But, at this point, I'm running into security issues that are beyond my measure to figure out, especially at 1:00 am with a beer headache. ";->" My other thing to try out was putting a simple XML-RPC interface on to the JobList. This was particularly interesting to me as I've found that while traditional "Zope" method calls should - in theory - work fine with something like XML-RPC, they seldom do. Sometimes it's because too much HTML is returned from a call, but most of the time lately (for me at least), it's that I want the server to do some processing of the results before sending them out to the client, using the relatively simple data types afforded to XML-RPC. As a result, I've been adding in extra Python Scripts particularly for XML-RPC, and letting them work in the proper places either via acquisition or some other clever tricks. It's not a bad system, but it's not exactly formalized or repeatable, since it's not in a formal Product. In Zope 3, this is different. I wrote a simple XMLRPCView class. 'View' objects in Zope 3 have two state members - 'request' (the incoming request object), and 'context' - the object the View is applied against. So, for me to add in the new functionality whereby I could just get a list of approved Job titles, I wrote the following Python file in my JobBoardEditor product:

from Zope.Publisher.XMLRPC.XMLRPCView import XMLRPCView
from ZopeProducts.JobBoardEx.IJob import JobState
 
class JobListXMLRPCView(XMLRPCView):
    __implements__ = XMLRPCView.__implements__
 
    def listJobTitles(self):
        joblist = self.context
        job_ids = joblist.query(state=JobState.Approved)
        out = []
        for jid in job_ids:
            out.append(joblist[jid].summary)
        return tuple(out)

Then, I added the following to JobBoardEditor/configure.zcml (after adding xmlns:xmlrpc='http://namespaces.zope.org/xmlrpc' to the head zopeConfigure element):

<xmlrpc:view
    name="joblistmethods"
    for="ZopeProducts.JobBoardEx.IJobList."
    factory=".JobListXMLRPCView." />

With this configuration statement, I've added a new View to be published on the XMLRPC channel (which in Zope 3 runs on a different port than normal HTTP requests, which is probably wise) for objects that implement the IJobList interface. I was able to do all of this outside of the JobBoardEx product. I just had to ensure that the Product was added in after JobBoardEx by using the site's products.zcml file to affect the ordering. After restarting Zope 3 (which is a very slow restart on this machine), I was able to do this:

Py$ s = Server('http://localhost:8281/zoo/joblistmethods')
Py$ s.listJobTitles()
['test test test']

I actually had created two jobs through the web interface, but had only approved one. So I ducked in to the web interface to approve the other job, and then made the call again:

Py$ s.listJobTitles()
['test test test', 'the other job']

So, what are some benefits of this? One that comes to mind is issue trackers. Earlier in the day, I was writing a Python script to farm through some Tracker data and format it nicely for XML-RPC, with the intent of writing a simple AppleScript Studio application to list pending/accepted Tracker issues. I did this informally, dropping a Python Script into the folder above a particular tracker. Ultimately, it didn't work - and I think a lot of the blame goes on XML-RPC's utter disregard for semi-proper security. Since Zope's always published objects on the web with regards to web security standards (or embarrasments, depending on your view) such as 'Basic Auth', it's had problems with the "security by passing in arguments" design of many XML-RPC API's. But the point I was really going for was packaging. Even if the Tracker Issue finding Python Script had worked over XML-RPC, now I have to find other places to put it by copying and pasting it, ultimately adding another name onto an ever growing namespace. With Zope 3, however, I could write an XML-RPC view particularly for the application I was designing as a normal Python component, and install and configure it as necessary (and hopefully that configuration work will be better than copying and pasting plain Python Script code). I can name it specially, essentially adding a new namespace for my application. I can distribute it to other users fairly easily. Another example would be implementing the Blogger API not as a new weblog product for Zope, but as a view/adapter component that publishes on the XML-RPC channel, and communicates with other Zope components, either built in ones or third party. In summary - my first tangible Zope 3 experience in quite some time has been hopeful and helpful. There's still a long way to go, but the kernel is shaping up nicely. The pattern driven / "extreme programming" sprint driven development has yielded a decent - but still shifting - code base that should be stronger and simpler than Zope 2. Sometimes, there are enough levels of indirection in Zope 3 to make it look more complex, but so far most code has been easier to follow and trace than Zope 2 (although there are a number of empty folders/packages that probably need some brute force removing from CVS) - at least, it's usually easier to tell what's going on (and even this has an at least - at least, once you start learning the new paradigm). Zope's ancester, Bobo (the kernel on which Zope is still based), was all about abstracting the means of publishing an object on the web away from the object itself. Bobo, and then Principia / Zope 1.x, built upon this, but primarily in a single-UI / single protocol type way. It's obvious today that there are many ways of looking at things on the web, including never actually using the web itself. Zope 3 brings us back to the notion of an object publisher being able to serve up objects on different protocols. Zope 2 offers this today, but there is great difficulty in making WebDAV, normal HTTP, FTP, and XML-RPC all live harmoniously in the current design. And finally, Zope 3 should yield a usable scalable means of adapting the works of other developers into new solutions by providing better control of product/service/view configuration and overrides, such as adding a new XML-RPC API to someone elses bug tracking system without having to alter that bug tracking system, or use secret Python hacks to alter behaviour.

Organization Objects

Mon, 10 Jun 2002 21:43:36 GMT

Ken Manheimer has also posted a proposal (a little bit dated) about what he calls Organization Objects, and a really good companion paper about the motivations for organization objects. The motivations paper discusses how the parent/child and table of contents relationship(s) were done for ZWiki, and how Organization Objects (which bear similarity to XLink) would have benefited the application. A bullet point in the Organization Objects proposal that I really liked is:

Living with only links and searches is like living in an imaginary world where every room is connected to every other by transporters - it lacks a basis for regionality, neighborhood.

In other words, it lacks progressively grouped regions by which you can realize "where you are".

ZWiki and logical structures.

Mon, 10 Jun 2002 19:59:30 GMT

ZWiki is a sehr-cool beast, as far as Wikis go. A very attractive feature, seen all over the Zope.org web site is Ken Manheimer's work on page/parenting relationships. This makes it so that Wiki pages, although stored in a flat namespace (all in one folder) can appear to be hierarchical, depending on which page generated which page (parenting can be altered of course). This in turn leads to cool things, like a structured table of contents (see the Zope 3 wiki's TOC Here). It's especially cool in that it's fairly easy to change the hierarchical structure of the Wiki - by looking at a page's backlinks, one can reparent a page to one or more of its linkers. Essentially, new logical structures can grow independent of the physical structure. I've used a similar feature in a recent simple content system, wherein all documents were stored in a single folder, but the users entering content could classify documents in one or more categories. The main pages on the site were basically database queries (actually, catalog queries) based on the classifications. Thus, the site was built out of a simple logical structure rather than a physical one, which allowed documents to appear in more than one place if they needed to be. It's no unique concept, "Radio" and some other blogging tools allow this, much to my delight. In the simple compound system I did for that customer, the flat namespace also allowed simple inter-document link management. The author could say "document A links to document B", and when document B was deleted, the link to it would also evaporate. For some reason, doing deep inter-object linking in "Zope" is still tricky business, but there's hope on the "Zope 3" horizon (some of which looks like it may be backported to Zope 2).

Intent, and human editable XML.

Wed, 05 Jun 2002 18:49:53 GMT

There's been an interesting debate on the "Zope" 3 development list about ZCML - the new Zope 3 configuration language. The debate ultimately seems to be over what I view as "human readable" XML versus "machine friendly" XML. There is a lot of power and usefulness in XML, but the proliferation of namespaces and unknown attribute handling has taken the human out of it, I think. Intent gets lost. Anyways, they're sticking with the current ZCML format, which can be seen in practice here. It's not horrible, but it could be better. Personally, I found the Servlet Web-App Descriptor to be much easier to work with, as per the Jakarta/Tomcat sample starter file. It's more verbose, which requires more typing (it seems that programmers really hate to type), but the intent is much clearer. Intent. It's valuable. But sadly, so easy to cast off.

Marshalling - the good point of XML-RPC and SOAP.

Tue, 07 May 2002 23:07:28 GMT

Looking back at Sam Ruby's article, Google's Genius, he mentions my favorite point in favor of SOAP/RPC:

Perhaps the most illumining part of Paul's essay is when he describes his optimized doSpellingSuggestion API. In this case, he declares that XML is overkill for the job. Unquestionably, omitting XML in some cases creates a tighter data stream. It can also require custom marshallers and parsers to be written. More tradeoffs to consider.

The second to last sentence is important. In my view, XML "scraping" is not much better than HTML "scraping". The Google API's were immediately usable in everything from Ruby to Python to AppleScript to Frontier/Radio, and more, with only a SOAP library needed - nothing specific to Google. The calls were Google specific, yes, but the client immediately understood the results of the call. Even though it's a silly application, I would never have even attempted to write something like HyprSwank, as mentioned in "AppleScript Studio, XML-RPC, and Zope", if I had to parse the results out of my data structure myself. I'm not sure what XML parsing libraries even exist for AppleScript, but I'm sure if they do (or were to) exist, it couldn't be any easier to use than: tell application "http://euc.cx/" to set link_list to call xmlrpc {method name:"hyprSWNK", parameters:{}} Or in Python:

import xmlprclib, pprint
link_list = xmlrpclib.ServerProxy('http://euc.cx/').hyprSWNK()
pprint.pprint(link_list)
[{'sitename': 'mobileffe', 'link': 'http://www.mobileffe.com/'},
 {'sitename': 'Prada', 'link': 'http://www.prada.com/'},
 {'sitename': 'ACFny', 'link': 'http://www.acfny.org/'},
 {'link': 'http://www.peopleusedtodream',
  'sitename': 'People Used To Dream About The Future'},
 {'sitename': 'David Lynch', 'link': 'http://www.davidlynch.com/'},
 {'sitename': '.tiln', 'link': 'http://tiln.net/'},
 {'link': 'http://www.timecube.com/',
  'sitename': 'educated people are stupid cowards'},
 {'link': 'http://www.antigirl.com/',
  'sitename': 'absolut antigirl !(absolut cybele)'},
 {'sitename': 'no ~ type', 'link': 'http://www.notype.com/'},
 {'sitename': 'meta.am +=', 'link': 'http://meta.am/'},
 {'sitename': 'fals.ch', 'link': 'http://fals.ch/'},
 {'sitename': 'infotron', 'link': 'http://infotron.web.fm'},
 {'link': 'http://www.m9ndfukc.org/korporat/',
  'sitename': 'aaaaaaa n t i o r   p;uss'},
 {'sitename': 'nato0+55+3d', 'link': 'http://www.eusocial.org/'},
 {'link': 'http://www.angelfire.com/electronic/campmsp/',
  'sitename': 'themoonstealingproject'},
 {'link': 'http://artists.mp3s.com/artists/42/musiquemotpol.html',
  'sitename': 'musique:motpol @ mp3.com'},
 {'link': 'http://www.helmutlang.com/',
  'sitename': 'finest cotton armbags since 1997 (HL)'},
 {'sitename': 'One Bit Louder', 'link': 'http://mi.cz/obl/'},
 {'sitename': 'purple', 'link': 'http://purple.fr/'},
 {'sitename': 'OFRPublications', 'link': 'http://www.ofrpublications.com/'}]

While I could have written my own parser, written my own format, or spent time researching common XML formats and then scouring the web for an already written parser for my language or sitting down with a copy of "XML and Python", I chose not to. For as much as I rag sometimes on some of XML-RPC's shortfalls, it's much better than doing all of that! It gives one common format for a common internet use, and has spread around to many languages. If I had to write my parser, or wait for someone to write one, or deal with DOM navigation, in order to deal with GoogleML, I'd be much less curious about "hmm, what can I write today to take advantage of that?". A nice thing that Bobo got right from day one was to implement and handle marshalling of incoming HTTP requests in such a way that my code never has to go through a "is it a list? is it a string? is it a string I can convert to a list?" somersault again. Or at least, not often.

WSDL generating

Tue, 07 May 2002 07:02:04 GMT

Earlier, I started writing up some thoughts in response to Jon Udell's Web Services post today, particularly the part about WSDL Autogeneration. Jon says:

The classes you'll want to annotate for such treatment should, in many cases, be abstractions of those that implement behavior. Creating such abstractions is, of course, more work -- and the kind of work that doesn't easily yield to automation.

Sounds like Interfaces. Which is where my post was going earlier, but I found flaws in my thinking. While I think the following is possible, and may actually work, it will invariably get more complex than this: wsdl = WSDLWriter.generateForInstance(obj, onlyInterface=IBlogger) shrug. I'm too tired right now to explore this notion too much. The issues I started running into is how much to tie web service or security related metadata attached to an Interface (ie, abstraction) to an implementation. It's an issue they struggled with as Interfaces were starting to get heavily used for "Zope" (particularly in the growing Zope 3 architecture), and I believe such information has been moved to configuration files(?). I could be wrong. Anyways, as long as we're going in the direction of generating WSDL out of code versus generating code out of ~~IDL~~ WSDL, things aren't all that bad. Yet.

Jaguar Notes

Mon, 06 May 2002 21:33:33 GMT

Apple's Jaguar Page is up. Something hypr-cool? Sherlock 3 is actually Karelia's Watson, a really cool app showing how a desktop application can make use of web available data without succumbing to Microsoft's "Everything IS a web page" type interface.

Verbosity and Web Services, again. Does Dave Winer really get it?

Sat, 04 May 2002 09:07:25 GMT

Forward: a few hours ago, after getting home from dinner with friends, I was reading more on Web Services, and found this article on Wrapping Web Service APIs on ORN by Stephan Figgins. It somehow led me back to an old Scripting News post that somewhat rankled me when I first read it. I'm finally posting my response. At 2AM, saturday morning. Does Dave Winer get Web Services? This posting talks about the overhead involved in publishing a web service via .NET. I admit, my experience with Radio and Frontier is still very small. But, at least with "Radio", you have to write your Web Services script in a special folder, Web Services. How is that not overhead? Now, you're writing a single script adapter to another part of the system in order to publish it on the web services channel. This may make sense in an environment based on pure scripting, but what about real persistent objects that are already on the web - objects that are both Data and Behavior? "Zope", and Bobo before it, have been built on this concept from day one. Many a year ago, Amos Lattier wrote an article called The Bobo Way. I'm going to quote his article here, because (as I've said before), this sounds like familiar ground:

For example if your app keeps track of company employees, you will probably want a separate Employee object for each employee. That way you can access these objects with URLs like: /Employees/amos/set_menu?lunch=spam This URL assumes that Employees is a mapping object that contains Employee objects. Employees["amos"] is an Employee object that represents the amos employee. The above URL calls amos' set_menu method with lunch=spam for arguments: Employees["amos"].set_menu(lunch=spam)
Ed: this could also be Employees.amos.set_menu(lunch=spam) For contrast lets look at a non-bobo way of doing the same thing: /set_menu.py?empid=amos&meal=lunch&food=spam

It seems to me like an awful lot of XML-RPC interfaces are not much better than this last example. They're usually a single function that is handed some sort of key to operate on another object with, rather than going to that object directly. It defeats polymorphism, it defeats generalization, and ultimately it can lead to a large and unwieldy adapter layer, tucked away in a Web Services directory somewhere. There are merits to this design. You are basically writing an Adapter pattern of sorts, mapping a Web Service friendly interface into whatever the internal system really has. And, if that's the only gateway into your system from the outside, you have some level of security by limiting the amount of access to a collection of XML-RPC dedicated functions instead of opening up access to every potential object. But there are merits to the other design too. In theory, you can program Zope the same way on the inside as on the outside, so long as you have the credential to do so. You have instances of classes out there, on the web, already. .NET seems to be following this route somewhat. Doing Web Services by this route is scarier. Why? Security for one reason. And, you just don't want to turn every single method on the object to be callable over the web, or - at the very least - you want to attach conditions. This is what Microsoft is doing. Let's look at how a simple 'return hello' class for Zope looks, disregarding any Zope OFS framework stuff (making the class addable through the web interface). Putting an instance of this class in a Zope tree would yield the same results over XML-RPC as calls to this .NET example would:

from Security import ClassSecurityInfo
from Persistence import Persistent
from Globals import InitializeClass
 
class Hello(Persistent):
    security = ClassSecurityInfo()      #Used to do declarative security
 
    security.declareObjectPublic()      #Make these objects inherently public
 
    security.declarePublic('sayHello')  #And make this method public
    def sayHello(self, name):
       """ Say hello to 'name' """
       return "Hello %s" % name
InitializeClass(Hello)                  #This processes the security declarations

Now, it's about the same overhead as the Microsoft ASP.NET example. note: There's more overhead involved with Zope itself in order to fit the Hello class into the Zope framework, but this is purely an example. This could have been easily written as a Python Script object, where the security settings could be set through a web UI.. Why do all this? Because web services as API's are ultimately programmatically exposed. There are two ways this is done:

Declarations, either in code or configuration (ie, xml) files.
Writing separate handlers, and only exposing those to the web

The first is the "Zope" way, and apparently the .NET way. At some point, you're taking code that exists already and saying "yes, this is a web service". The second seems to be the Radio way, where you write a script that calls into other existing code, and say "this script is the web service". Sometimes, the amount of overhead is equal. But I think relegating all Web Services to being scripts and functions in a special folder or singleton object weakens their potential. Likewise, not all existing web-published code is ready to be made into a Web Service. Both ways are valid. But, there's got to be a better unification. Dave needs to understand the declarative way. It may look more verbose on a silly little Hello World example, but I have access to thousands of methods exposed via XML-RPC that are done so automatically via Zope's similar security declarations. That's a lot more than I'd have access to if I have to write those methods in a special place. So, here's another verbosity example. Let's say there's the following bit of code in a Blog Entry class:

class BlogEntry(...):
   security.declareProtected('Edit Entries', 'editPost')
   def editPost(self, content, publish=0):
      """ Set the content of the post, and publishes it if publish is true """
      self._content = content
      if publish:
          self._publishedContent = content
      return "OK"      #simple return value

And, for simplicities sake, lets say we had a flat structure for all entries to make URL's easier, and we have an entry identified as '123'. So, to edit it via URL. Hmm, this is almost REST-like: .../Posts/123/editPost?content=boy+howdy&publish:int=1 And do to it via BCI (ZPublisher.Client):

myPost = ZPublisher.Object('.../Posts/123', username='bob', password='bobby')
myPost.editPost(content='Boy howdy!', publish=1)

And XML-RPC in Python. Note that in order to do this, due to Zope's built in security, you either have to have a hacked XML-RPC library locally that generates authentication headers, of have RPCAuth by Nathan Sain (which I haven't had time to test yet) installed on Zope:

myPost = xmlrpclib.Server('.../Posts/123')
myPost.editPost('Boy Howdy!', 1))

These are very similar, but ZPublisher.Client was doing this long before XML-RPC. Why? Because Zope was already doing distributed objects (of sorts) on the web, translating HTTP requests into object calls. It only makes sense that there be some simple client lib. Now, to implement this as a proper Blogger API, and do it the way that Radio style web services are done, instead of necessarily having all of those security declarations on the BlogPost class itself, I would instead have to write this:

def editPost(appkey, postid, username, password, content, publish):
  """ Lookup the post by its ID, verify that the user can access it,
      and set its content and published flag """
  thePost = Posts[postid]
  ## security assertions based on username/password would go in here, somehow.
  thePost.editPost(content=content, publish=publish)
  return 1

Now, this isn't too bad. But, it's a similar amount of overhead to turn an otherwise already existing published web method as a Web Service. Huh. As people start exposing ever more valuable resources as Web Services, or even REST, it's no wonder complications arise. As we move beyond the 'getStateName' example and start getting into exchanging business data (Microsoft's heavily advertised 1 degree of separation), more care must be taken. I don't want everything I write automatically turned into a Web Service. I don't necessarily want to have to write extra adapters either. To sum up and say it all over again, the way that "Radio" seems to promote for Web Services is easy. And simple. But you're effectively writing scripted adapters and bridges into other code, something that could turn out to be a maintenance nightmare. The way that "Zope" has promoted for years (even though it's not a terrific Web Services player, sadly) says that "Objects and their methods are already published on the web. No gateway scripts needed.", but with that comes the price of maintaining security declarations similar to C#.NET's ASPX's declarative Web Service calls. Dave calls the latter too much overhead. I say it's the other way around. It should be easy to write Web Services, but you should have to think about what you publish. Those declarations aren't much worse anyways than the long signatures verbose languages like Java can make you write (protected final synchronous int Bob()).

Accessory Update

Sat, 04 May 2002 04:29:33 GMT

Updated "EUCCI accessories" document, which covers the XML-RPC services I found already existed on my old Zope 2.2 server, as well as the new one I wrote today.

AppleScript Studio, XML-RPC, and Zope

Sat, 04 May 2002 01:51:40 GMT

I found this article while browsing around today about using AppleScript Studio and Filemaker, and I finally had the nerve to do what I've been meaning to do for a long time - expose the hypr list of urls for euc.cx as a list of mappings, and start learning AppleScript / AppleScript Studio. I did it. Pretty easily too. I followed the first half of the article, but instead of using Filemaker to fill in the data source, I used a new DTML Method on my site called hyprSWNK. I got that app going in about sixteen lines of code - not bad considering the verbosity of AppleScript. I spent the second half of the evening adding in support to open the URL of the selected row in the table. I had some problems, because OmniWeb was not responding to the AppleScript statement I was using, but eventually when I tried Internet Explorer, it worked fine. Pretty cool for a couple of hours work.

Sun, 21 Apr 2002 17:28:24 GMT

EUCCI accessories, a new story covering the "euc.cx" XML-RPC API.

A simple tapping into a hitherto unknown euc.cx XML-RPC service

Sat, 20 Apr 2002 21:36:47 GMT

I've finally started playing around with the development aspects of Radio, and plugged it into a simple XML-RPC service running on euc.cx. euc.cx is running on an old Zope server (Zope 2.2 or earlier, meaning pre-pythonscripts). It's primarily a static site, with a few little dynamic pieces. One is a DTML method called rsong, which returns a random entry from a list of EUCCI song titles. It's a public method (used on the main page, maybe a couple of others), so I wondered if XML-RPC would work out for me in this situation. It did. See, that bit's easy. But I'm still annoyed about the whole XML-RPC authentication situation. As I wrote in a recent story, Zope should play well with web services. But the fact that Zope takes security quite seriously makes it very difficult to expose anything other than public methods, unless you hack your local XML-RPC client module/library/whatever to do HTTP Basic Auth. *sigh;*

Zope, Web Services, why BCI was cool and why I sigh at noon.

Fri, 19 Apr 2002 06:09:35 GMT

New story here regarding Zope, XML-RPC, Web Services, and the cool stuff Zope/Bobo was doing oh so long ago, and my frustration that it's still not plugged into the Web Services world as it should be. Part of this is the fault of protocols like XML-RPC, which doesn't take into account things like Authentication, which is so critical and deep to how Zope works that it's harder to match the two up than it should be. Part of it is due to the hodge-podge development that's gone on over the years (which is finally being addressed in Zope 3), especially in regards to the protocal-handling pieces.