Web Hosting RPC Server
Fri, Oct 15, 1999; by Dave Winer.
This spec describes the server side of a web hosting service, like GeoCities or Tripod, but open to content managed in environments that support XML-RPC.
It's a key interface for connecting content development and authoring platforms such as Mac and Windows 98/95, with scalable server platforms running on Unix and NT.
The test server is up and running. There's a Frontier test script at the end of this document.
Send your XML-RPC messages to: 206.204.24.2, port 80, path /RPC2.
The only valid username/password combination on this server is guest/guest.
Only use this server for testing. There's a 512K per client storage limit. Store small files. We will erase the test directory when UserLand offers this as a supported service. Be kind to our server and we'll keep it running. Thanks!
webHost.put (pageTable) returns a struct
pageTable is an XML-RPC struct that describes a page that's to be stored on an HTTP server.
There are five required members of the struct: username, password, bytes, mimeType and relativePath.
username and password are as described in the DG XML-RPC interface.
bytes is a base64-encoded string representing the information that's to be served when the page is requested. It's base64-encoded to save the trouble of escaping left-angle-brackets in HTML text, and to support binary data (e.g. gifs, jpegs).
mimeType is a string containing the MIME type of the bytes, e.g. text/html.
relativePath is a forward-slash-separated string, indicating where in the hierarchy assigned to the user this file is to be stored.
webHost.put returns a struct containing (for now) a single member, url, a string, which is the URL you can use to access this object. This allows each server to determine where and how it stores files and how they are accessed thru the web.
It's possible that the server will change the extension of the file, since some servers key off the file extension to determine how they serve a file.
There's no need for a "get" verb in this interface. You can get the data thru the web.
We considered using HTTP-PUT as described in RFC 2616, but it forces the user-agent to specify the URL, and in this protocol, we need this to be up to the server.
An implementation of this interface can provide extensions by allowing content to contain macros that evaluate as a page is served. This spec says nothing about the syntax of server-side macros.
An optional element of the pageTable -- textToIndex, a string, allows the webHost to implement a smart search engine. This string contains the content for the page, without including any template information, allowing the search engine to only index information that's relevant to readers. Support for this feature is not implemented on our test server.
local (server = "206.204.24.2", port = 80, procedure = "webHost.put");
local (htmltext = "<html><body>" + clock.now () + "</body></html>");
local (pagetable);
new (tabletype, @pagetable);
pagetable.username = "guest";
pagetable.password = "guest";
pagetable.bytes = base64.encode (htmltext, infinity);
pagetable.mimetype = "text/html";
pagetable.relativePath = "randomFile" + random (1, infinity) + ".html";
local (params = {pagetable});
returnedtable = betty.rpc.client (server, port, procedure, @params);
webbrowser.openurl (returnedtable.url)
Here's an example page created by this script. The server uses its discretionary power to insert the sender's domain name to keep my files from overwriting yours. It's crude, but it provides a target to shoot at. The eventual for-real implementation will key off a UserLand.Com cookie/member record.
We're especially interested in working with other developers on server platforms that allow developers working on Windows and Mac to store dynamic pages. Simple docs explaining how to add dynamic elements to a page will be helpful. We want to learn how the dynamic environments on Unix work and assemble a set of documentation that shows in one place how each of the dynamic environments work.
Frontier source
The source for the server is here.
|