Archive of UserLand's first discussion group, started October 5, 1998.

Re: Response to Flutterby

Author:Paul Everitt
Posted:10/27/1999; 4:51:15 AM
Topic:Response to Flutterby
Msg #:12385 (In response to 12368)
Prev/Next:12384 / 12386

Sorry to come in late to the discussion.

We have some experience in this subject over in Zope. Historically we've been out in front in thinking about the web as a big object system, treating URLs as nested object calls that pass (and marshal) arguments into methods. For us, XML-RPC takes this Zope benefit and extends it beyond web browsers and into other programming languages and applications. It's a platform thing.

In Zope 2 we finally added our multiprotocol, concurrent server (ZServer). With it the same transactional object system can be reached by HTTP, FTP, a telnet-like protocol, XML-RPC, WebDAV, FastCGI, PCGI, etc. Some folks are working on adding IMAP as a protocol. Application developers for the most part don't have to do anything special to make their objects available for different publishing systems.

One of the prime reasons to do FTP was to allow web editing tools like Dreamweaver and development tools like Emacs/ange-ftp to play ball.

The moral: FTP is not a distributed object system. This makes using a rich object system via FTP into an underwhelming experience.

The very first thing you notice is that FTP doesn't have anything like Content-Type. This makes client and server interpretation of what the damn resource is into a guessing games of filename semantics. As an object guy, I just hate the crap out of that.

Next, FTP doesn't have a transparent security system. I really like the progression of techniques in HTTP, from Basic Auth, to Digest Auth, to SSL 2, to SSL and client-side certificates. For the most part this is all transparent to application developers, as it is part of the protocol negotiation instead of the payload.

How about other request/response semantics? Well, FTP gives you no request semantics, other than the operation, and one response semantic, being the response code. HTTP has a rich and extensible set of headers for both the request and response negotiation. Someone in the Zope community is working on adding an "XMLRPCMethod" product to Zope with caching in it. He wants to let the server express caching policies to the client. HTTP already has a facility for this.

Thus, I take issue with Dan Lyke's assertion of: "it's a reimplementation of systems for which perfectly serviceable protocols already exist." While it is true that FTP, SMTP, NNTP, et al. have spent decades covering important territory, there is definate lossage in viewing them as transports for a rich object model.

I'll also take issue with Dave's last sentence above about HTTP POST. Looking at the HTTP methods that WebDAV adds, well, there are a lot of interesting verbs there besides POST, such as discovery of properties, etc.

That's it for now.

There are responses to this message:

This page was archived on 6/13/2001; 4:53:12 PM.

© Copyright 1998-2001 UserLand Software, Inc.