Archive of UserLand's first discussion group, started October 5, 1998.
Re: Response to Flutterby
Author: Ken MacLeod Posted: 10/27/1999; 7:08:48 AM Topic: Response to Flutterby Msg #: 12399 (In response to 12385) Prev/Next: 12398 / 12400
You seem to be comparing FTP to XML-RPC, which isn't the issue. The issue is comparing FTP to the Web Hosting Protocol.
I understand Dave's reasoning for not patterning after FTP or WebDAV, we simply disagree. I don't have an issue with reimplementing existing protocols in a new, consistent protocol. I do have an issue with inventing new interfaces (higher level protocols) that are very similar to existing protocols but choose to be completely different. I believe Dave understands my reasoning, and we simply disagree.
To view this issue from a different perspective, instead of saying what this new protocol can do that FTP or WebDAV "can't", why not take the perspective of "how can we take FTP or WebDAV and make them do what we wan't". Right now, the Web Hosting Protocol doesn't have much to do with versioning or resolving multiple user issues, so FTP (or straight HTTP) is a good comparison; if WHP were to mature to add versioning and multi-user capabilities, WebDAV would be a better comparison.
Before going further, let's stipulate that the protocol is transparent to the user, it's all just plumbing. Also note that the current WHP only specifies a PUT method, there is no other host maintenance methods. Note also that the recommended way to read the file back from the server is to use the "destination URL" that the WHP returns to you. Since doing an HTTP GET causes the file to be rendered by the server, you're not getting back the bytes that you PUT, WHP is currently a server-push-only protocol.
Now, what "can't" FTP do? If I understand correctly, the only feature the web hosting protocol needs that the existing FTP spec doesn't provide is a way for the server to communicate the mapped URL (from the user-relative directory used in the PUT to the HTTP URL used to browse the file). One solution was already suggested for this, use a new SUCCESS return code (251?) that returns the mapped URL. Another solution would be to implement a new request that provided all sorts of information about a user-space path (HTTP URL, content-type, encoding, etc.). By adopting FTP semantics, the growth path for WHP would be very clear for adding GET, rename, LIST, delete, make a directory, etc. If in addition to an XML-RPC interface, if WHP also supported the FTP protocol interface, a broad base of existing tools (like ftp clients, ftp libraries, BBEdit, or emacs/ange-ftp) would be able to use WHP directly without modification, with the noted limitations (the mapped URL is not presented to the user) -- that's OK though, that's a cost for not supporting the extensions that many power-users would be willing to accept to use their existing tools or libraries.
Then, what "can't" WebDAV do? Again, returning the mapped-URL. You've suggested that an HTTP header could be used for straight WebDAV. Since we're talking about an XML-RPC interface, this would come back as a member of the
. Basing WHP on WebDAV would also provide a clear growth path. Note also, WebDAV semantics could also be added to the FTP protocol.
To be clear, in no way am I suggesting that WHP 1) should be implemented as an FTP or WebDAV protocol (though someone could do this as an add-on), or 2) that WHP needs to implement more than a PUT at this time (that's all Dave's CMS needs right now). I'm simply trying to suggest that basing WHP on an existing protocol (and stating which one) will provide a clear growth path for WHP for when these features are needed, and even allow for others to more easily contribute implementations because the API growth path is already well known.
Correction:
WHP also supports transmitting the MIME type and a string just containing the content (not template information) that can be used in search engines. FTP and WebDAV semantics can both be extended to support that, and an XML-RPC interface could support that inherently.
This page was archived on 6/13/2001; 4:53:13 PM.
© Copyright 1998-2001 UserLand Software, Inc.